[Bf-committers] version naming
l.frisken at gmail.com
Sun Apr 11 08:46:06 CEST 2010
2.5x wasn't supposed to be the final goal was it? Was it not 2.6 that
would be recognised as stable? Maybe I am wrong there, but I do think
that the decision on the version name shouldn't be based only/largely
on such technical reasons. Thankfully, i've got no urge to say
On 4/10/10, Campbell Barton <ideasman42 at gmail.com> wrote:
> 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
>> 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
>> 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.
> Bf-committers mailing list
> Bf-committers at blender.org
Sent from my mobile device
More information about the Bf-committers