[Bf-committers] version naming

[Jeroen Bakker]

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)

Regards,
Jeroen.

Tom M wrote:
> Hi all, on the docboard list there was an inquiry of exactly what the
> final version name will be after we exit alpha and beta.
>
> Ie will it be 2.5final, 2.6, 3.0 etc.
>
> Given that people are working on video tutorials now, they don't want
> to say the wrong version name and confuse people.
>
> I'll lay out my own views briefly,
>
> I'd personally prefer we move to a whole number versioning system and
> use numbers after the decimal to convey bug fixes.
>
> So next version would be 3.0, the following would be 4.0 etc.
>
> My reasoning for this is multifold
>
> 1) Under the current method a user cannot tell at a glance whether any
> particular version is a bug fix release or a major feature improvement
> or bug fixes
>
> 2) Users familiar with typical version naming can easily be confused
> with documentation - if a tutorial is written for 2.49 then the
> logical inference is 2.50 is almost exactly the same and probably only
> contains bug fixes or other minor differences.  So those of us doing
> new user support have to explain that 2.43 is drastically different
> from 2.49 in terms of UI, and so tutorials written for the former
> aren't perfectly transferable to the later.
>
> 3) Most media (magazines, websites, television) are used to more
> standard naming systems and thus unless they are highly CG focused
> ignore minor number increases.  By switching to a different versioning
> system I think it will increase the amount of coverage and hence
> attract more new users and developers.
>
> 4) Individuals who have control over software installation and
> purchase decisions who have no technical expertise (a extremely common
> case - think schools, and most businesses) use version numbers to
> evaluate software.  (No we aren't going to install 2.50 it is only a
> .01 difference from 2.49 so would be a waste of our software
> administrator time).
>
> I've talked with some others,
>
> Matt Ebb prefers a two decimal system so 2.6.0 2.7.0 etc. with bug
> fixes being 2.6.1 etc.
>
> Some other open source projects do odd numbers are development and
> even are stable
>
> so 2.6.0 would be the next stable; 2.7.0 would be a development
> version, and 2.8.0 would be the stable version after that.
>
> So that documenters and authors can begin working on final versions of
> their docs without leaving in wrong/confusing terms I think we should
> try and make a decision on this soon.  Preferably this up comming
> meeting.
>
> LetterRip
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>