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