[Bf-committers] version naming

[Campbell Barton]

On Sat, Apr 10, 2010 at 9:45 AM, Jeroen Bakker <j.bakker at atmind.nl> wrote:
> Hi all,
>
> The impact of changing a version number:
> For every release increase mayor: 3.0, 4.0 -> we can only make mayor 7
> releases (limitation in file format)
> so I disagree with mayor increase, except if we can find a way to place
> this in the current file format
> remove the last digit 2.5, 2.6  -> we have to go to increase the mayor
> within 2 years file format can hold 33 releases before reaching the
> limitation
>
> Current way: we can still do 240 releases.
> When choosing a new version numbering, it has bigger technical impacts.
> File reader, upwards and downwards compatibility.
> The current implementation also has some drawbacks:
> patches are not recognized (249a, 249b) when a big patch has to be done
> impacting DNA+conversion it can not be placed in the filereader without
> tricking.
>
> So IMO: mayor.minor.patch + (2.5.1, 2.6.0)

Thanks Jeroen for bringing this aspect of version numbering up.
I'm not really interested in discussing this but for the record, agree
with your comments above, +1

One other reason I'd hold back from 3.0x is the api for the first
release of 2.5x wont be at all stable for a while.
- Catch 22, people wont test until a release and we dont have the
resources for really good evaluation of our apis, so a few iterations
is normally needed.