[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