Blender Version numbering

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

Post Reply
lvella
Posts: 0
Joined: Wed Jan 21, 2009 6:50 pm

Blender Version numbering

Post by lvella »

I realized some time ago how difficult is to some open source projects to consistently evolve their version numbering. Seem that, as time passes, it is harder to change the major number of their versions. This effect is illustrated by this table:
http://en.wikipedia.org/wiki/X_window_s ... se_history
Notice how it is increasingly hard to change the major version number. If things keep on like this, it seems we will never get X12.

This effect is obvious on Linux (1992: 0.01, 1994: 1.0, 1996: 1.3, 2010: 2.6.33.3). It seems to affect any project without regular release schedule.

And it is affecting Blender too. If after so many changes it will be called 2.5, when it will be called 3?

I am in favor of naming Durian release of Blender as 3, not 2.5. We must not fear we will run out of numbers to name the versions, there are plenty of them...

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv »

If things keep on like this, it seems we will never get X12.
Yeah, so? What's in a name (or number)? A rose by any other name or 32 bit hex identifier would smell as sweet. My personal preference for Blender is to use prime numbers for each version. But I fear we would eventually run out.

lvella
Posts: 0
Joined: Wed Jan 21, 2009 6:50 pm

Post by lvella »

So you may think names are unimportant, but the psychological effect on users of a slow evolving version number is that of slow development and little improvements. In extreme cases like Linux, it is hard even to speak of a particular version, and easy to get lost between them.

By the way, Euclid demonstrated that you never run out of prime numbers.

FreeMind
Posts: 0
Joined: Thu Mar 18, 2010 9:57 pm

Post by FreeMind »

I really have no idea why the new blender is not called Blender 3
I think it makes no sence, that after a completele rewrite with ultra mega super improvements we rise the version only by 0.11

The least what could be done right now is to call the first stable release 2.5
And after the "Rendering focus" and "modeling focus" call it Blender 3.

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv »

FreeMind wrote:I really have no idea why the new blender is not called Blender 3
Because we already have long-term plans for Blender 3. It is the version where Blender becomes an actual Python extension module and not just another program with an embedded Python interpreter.

The fact that Blender shows "ultra mega super improvements" and the version number only rises by 0.11 is just an example of the amazing concentrated awesomeness of Blender and Open Source development.

lvella
Posts: 0
Joined: Wed Jan 21, 2009 6:50 pm

Post by lvella »

stiv wrote:Because we already have long-term plans for Blender 3. It is the version where Blender becomes an actual Python extension module and not just another program with an embedded Python interpreter.
Well, maybe Blender with these super nice changes could be called Blender 4, and Sintel`s Blender could be called Blender 3.
The fact that Blender shows "ultra mega super improvements" and the version number only rises by 0.11 is just an example of the amazing concentrated awesomeness of Blender and Open Source development.
Actually, this fact simply corroborates my point.

nautilus986
Posts: 0
Joined: Sat May 01, 2010 3:48 pm

Post by nautilus986 »

Hi,

The version numbering system is perfect as it is. The reason why they use even decimal increments is to signify small updates that bring very large improvements. It's a way to make ambitious objectives seem as feasible as possible. It shows how strong the open-source community is, by making such large upgrades seem so small through their non-assuming numbering system.

I like it as it is, with this non-assuming and powerful numbering system. Odd decimal points can be used for alpha and beta releases of upcoming large revisions, even numbers for stable and production-ready releases.

Besides, calling each major revision of Blender Blender 3, 4, and etc is ungainly in my eyes.

matt77
Posts: 0
Joined: Fri May 07, 2010 3:12 pm
Location: Brazil

Post by matt77 »

I agree with the OP.
While developers and people close to the project understand that an increase of 0.11 in version means significant changes, other people like casual users, outsiders and general public cannot grasp this meaning. For them, this small increase in version number is seen as a small evolution.

So this is about marketing, visibility and competition with other softwares. People will not check to see if there are huge changes at each 0.11 increase in version number, they will disregard this advance as a little step, as small as 0.11.
It does not has to do with coherence, concentrated changes, or efficient open source development. It has to do with what people, users in general, will think, and they surely will not think, "Wow, blender has launched the next version, which is in number 0.11 greater than the one before, so there is a lot of changes".

best regards.

FreeMind
Posts: 0
Joined: Thu Mar 18, 2010 9:57 pm

Post by FreeMind »

Yeah, that's what I thought.
When normal people see such a small advance they actually think that blender 2.49 is almost the same as 2.5, like with a few fixed bugs or something...

I think it actually makes sense to ditch the x.xx format and just do the date format.

Like Blender 2010. Or something similar
Then people can see that blender advanced in one full year of development.

lvella
Posts: 0
Joined: Wed Jan 21, 2009 6:50 pm

Post by lvella »

Raising the thread from the dead, next Linux release will be called Linux 3.0. Last stable version of Linux was was called 2.6.39.1, so it seems Linux was suffering the problem I described here... until now!

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv »

Linux has been using the same numbering system since 0.99pl13 (version 0.99 path level 13), back in the Jurassic Era. That suggests the 'problem' was not exactly burning if it took decades to fix.

Personally, I am impressed by the passionate debate that version numbers inspire. Maybe it is from a focus on marketing over substance.

For reference, the next version of Blender will be 2.58 in a couple weeks, with 2.59 coming in August for Siggraph. We are moving to an 'every two months' release cycle. Feel free to factor that into your version number schemes.

ihenderson
Posts: 0
Joined: Tue Jul 19, 2011 9:42 pm

Post by ihenderson »

I agree with lvella in that I think what is clearly a major release would be better off with a brand new major version number.

Instead of merely qualitative measurement for psychological purposes, the major version number could follow more solid rules to communicate the fact that the files from a new major version will not be compatible with the files from a previous major version. Files from minor versions should still be compatible, so that it is safe to update if you are in the midst of a project. With the current numbering system it is unfortunately unclear when important points of file/API incompatibility actually are in the development cycle.

A major increase could also be used to clearly signify the point at which online documentation is duplicated for a new release, and the old documentation is kept in tact for people that still want to work on a project in the old version. Bugfixes could continue for the branch of an older major release even if it's features have been frozen, so people have the choice not just to focus on the unstable version.

It would also be good if major versions could be installed at the same time from a Linux operating system's repository, much like Python 2 and 3 can be installed at the same time. Whilst minor versions would be updated, and the old version overwritten.
FreeMind wrote: I think it actually makes sense to ditch the x.xx format and just do the date format.
I agree! A yearly release for major versions seems like almost a standard way of doing things (although it allows less flexibility), and using a year instead of an arbitrary number makes more sense to the lamen, most commercial software packages such as Maya and Houdini use this system.

Maybe what is really needed is a common (yearly?) major release cycle and version numbering standard that multiple free software projects could follow (voluntarily of course). That way new versions of software and libraries they depend on could be timed for new versions of OS's (Patient Debian user here, clinging on to Blender 2.49). I feel sad that this is too much to ask though. :(

Looking back at the example of X11, I think the reason we have not seen an X12 in so long is because so many, many programs rely on X, that a completely new version that changes the API and breaks compatibility would require a huge migration all across the realms of free software. So I think it makes sense that they don't change the number 11, although a completely new version of X does seem unlikely to happen.

Well anyway, in conclusion, please make the jump to 3.0! I can see no reason why not to other than that it will feel too big.

ihenderson
Posts: 0
Joined: Tue Jul 19, 2011 9:42 pm

Post by ihenderson »

Regarding my previous post. While poking around on Wikipedia I found a link to a version numbering system specification, authored by a co-founder of GitHub, and I would urge any developer who comes across this post to take a look at it:

http://semver.org/

The system is as simple as this:

X.Y.Z

X: Major version number, new features added, compatibility broken.
Y: Minor version number, new features added, compatibility kept.
Z: Patch version number, bugs fixed only, compatibility kept.

Post Reply