[Bf-committers] version naming

Tom M letterrip at gmail.com
Tue Apr 6 03:08:53 CEST 2010


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


More information about the Bf-committers mailing list