[XviD-devel] [RELEASE CANDIDATE] v0.9.1
suxen_drol
suxen_drol at hotmail.com
Wed Feb 12 23:16:18 CET 2003
On Wed, 12 Feb 2003 12:46:46 +0100 (CET) Christoph Lampert <chl at math.uni-bonn.de> wrote:
> On Wed, 12 Feb 2003, Michael Militzer wrote:
> > So that was my point: if we call the thing "stable", there shouldn't be any
> > known bugs or incorrect code included.
>
> Hm, would it really be worth to throw out code which is deactivated
> anyway just for a small group of developers who are supposed to read
> the docs before starting to work with the code?
> We could add a README which tells just what you discussed:
> ACTIVATED code is (hopefully) bugfree. DEACTIVATED code isn't, that's why
> it's deactivated, but it's not worth debugging it, because there is a
> corrected version is in CVS already and will be released soon anyway.
>
> gruel
dev-api-3 is growing too much i think. it appears to be stable as many
people are using it, but obviously not release worthy.
the major todo for xvid-1.0 are Ratecontrol, API and the VFW gui. RC and
API are kinda ready, but need intergration testing. to do that, we
really need another branch. i suggest the following development plan:
1. stable should be taged and branched as 'release_0_9_1'
2. merge dev-api-3 back into CVS_HEAD. non-major development stuff now
gets commited here.
3. tag & branch CVS_HEAD as dev-api-4.
4. commit current api and rc patches (thats me and gom) into dev-api-4
*only*. get it working, and merge back into head
another minor annoyance is the cvs/directory layout. maintaing cvs
branches between xvidcore,dshow and vfw is painful! how do people feel
about incorporating vfw & dshow into the xvidcore tree?
-- pete
More information about the XviD-devel
mailing list