[Bf-committers] version naming

[Luke Frisken]

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
anything else!

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
>> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

-- 
Sent from my mobile device

>From Luke