[Bf-committers] version naming

Wes Burke wes at cgcookie.com
Tue Apr 6 03:44:33 CEST 2010


Hi Tom,

I will interject quickly here mainly to share my interest/concern on 
this topic. Right now at CG Cookie we have been working to increase the 
users awareness of what build # we are working with on a specific 
tutorial. I can attest that  from background as an Artist/Game Industry 
pixel pusher, I wasn't aware of the specific meaning to the naming 
convention as mentioned below. Most likely due to my own lack of 
inquiry, shamefully. ;)

We have received some concerns from the community that our training we 
are providing on 2.5 builds will be obsolete on 2.6 as we have been 
holding our main recording for the (2.5 Beta 2 Doc ready) version for 
the past few months. We understand this not to be true, but the 
perception is that 2.6 will actually be worlds different then what we 
are currently working with. But in our eyes it is actually the 
polished/stable version of 2.5 correct?

I am not sure what the correct direction may be, but I wanted to at 
least offer help and any experience as an educator for the community we 
can.

Appreciate the time and the work you guys do to make it possible for us 
to do what we do.

Cheers,

Wes Burke

On 4/5/2010 8:08 PM, 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
>    


More information about the Bf-committers mailing list