[Bf-committers] version naming

[Chris Gunn]

I'd be in favor of the two decimal system. I find the current system to be a
little confusing.

I think the version number should represent large UI overhauls and\or
massive code rewrites, the sub version should be for minor upgrades and the
subsub version should be for bug fixes. This type of system makes the most
sense in my mind.

When a stable version is released the difference between it and the previous
developer release is almost zero. So I don't think a whole
new significant number should be assigned to it. It just confuses the
matter.

So I would have the next stable release as 3.0.x with the upcoming UI
overhaul being 3.1.x. x = being the number of released builds (alpha and
beta) before that release + 1. There has been so much changed since the
original v2.0.0 that blender deserves a version increase.

Chris

On Tue, Apr 6, 2010 at 11:44 AM, Wes Burke <wes at cgcookie.com> wrote:

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