[XviD-devel] [STATUS] XviD stable tree

[peter ross]

>When  these 3  things will  be done,  i propose  to release  our first
>official stable  x.y version. Michael  told me some people  were using
>API version for XviD versionning, i  don't like this idea but if it is
>already used, we'll have to stick to this version numbering scheme.
>
>So x.y will probably be 2.1

hello,

the api-version represents roughly the state of xvid, and having a
seperate 'xvid version' might be confusing.

2.1 and 3.0 are really high numbers. how about calling the current
version 2.1 as "0.2.1"

#define XVID_MAKE_VERSION(A,B,C)   (((A)<<16)|((B)<<8)|(C))

A = major version number :
    incremented when api changes significantly.

B = minor version number :
    incremented when the api is modified, but remains backwards
    compatible with the same major version.

C = stable release number :
    increment everytime we consider this "major.minor" stable.
    for example. we do our first big stable release, call it v1.0.0.
    two weeks later we find and fix a bug. this bug does not affect
    api, but requires us to release a new stable version. so we call
    this v1.0.1, and tag it as release_1_0_1.

whatever works, as long as we dont end up with "GNU XVID 21.0" in ten
years. after version 10 people loose interest in your product...

-- pete
:wq!

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com