Open source versioning conventions

[zolistir87]

Hello!

I would like to know more about the versioning conventions in the open source world. What is an alpha software? What is beta sotware? When does an application go from 0.1.1->0.1.2 or 0.1->0.2 or to 1.00?

Thanks in advance.

[ken_yap]

There isn't a single standard, it's up to the author(s). Similarly it's up to the author(s) when they feel something is ready for a particular stage. As for alpha and beta, here's the page in Wikipedia about it, though it is not specific to open source, and the page is flagged as needing work.

Software release life cycle - Wikipedia, the free encyclopedia

There's also a link from Wikipedia to this segment of a document:

Maintaining a Project: Interacting with Users

[TaraIkeda]

Also consider that a lot of linux apps can be considered alpha or beta quality in the normal versioning system but really most of it is very stable none the less.
The traditional versioning system is thrown out the window in linux as software that is say version 0.4.5 might be rock solid.
Or some of it might be unstable, but thats why I like linux: never know what works until you try
And some "betaware" can be more stable and sturdy then the final version, I have seen this happen both in the windows world and linux world.

[Knurpht]

Quite interesting matter this is, aspecially the alpha / beta issue. Years ago an alpha release would just give you an idea of what something was going to be. In beta's you could find some functionality, but still glitches, not only in the GUI.

Today I'm running Factory which is a whole system in beta state and it is rock stable already

[ken_yap]

In open source you will see a range of treatments of the issue of marketing. A rather technical project may not care much about version numbers and keep calling themselves 0.67 or something like that for ages even though the functionality is rock solid. On the other extreme, distros and programing languages have jumped version numbers to make themselves look good, e.g. Java 1.5 got renamed to Java 5 and so on and I seem to remember that Turbolinux made a similar renumbering.

[TaraIkeda]

Originally Posted by Knurpht

Quite interesting matter this is, aspecially the alpha / beta issue. Years ago an alpha release would just give you an idea of what something was going to be. In beta's you could find some functionality, but still glitches, not only in the GUI.

Today I'm running Factory which is a whole system in beta state and it is rock stable already

I too am running beta software, testing out KDE 4.3 beta 2.
Its rock solid so far and plasma has only crashed on me once, while KDE 4.2.4 plasma crashed on me numerous times.

[rajko_m]

zolistir87 wrote:

>
> Hello!
>
> I would like to know more about the versioning conventions in the open
> source world. What is an alpha software? What is beta sotware? When does
> an application go from 0.1.1->0.1.2 or 0.1->0.2 or to 1.00?

As other pointed out, in open source that varies from project to project.

Open source as development model has no specification stage before coding
begins, that gives base for implementation of features, and that will be
expanded only if customer wants to pay more, or marketing research makes
serious case where missing feature can hurt product sales.

In open source product creation is interaction between developers and users,
so new features are added, or dropped, on the fly. That is the reason that
some projects use alpha, beta, release candidate, release for each bigger
change, and version stay for ages in 0.1 to 0.9 range, and the other are
happy when basic functionality is provided and declare 1.0 at that point.

In general, my feeling is that majority of projects use:
- alpha as feature implementation stage,
- beta bug removal, no more features
- RC and release, when serious bugs are solved and few minor bugs are left
in the bug tracker.

The version number in that sense can be
0.7.1 for alpha
0.7.9 for beta and release candidates
0.8 for release
and then the cycle begins.

BTW, this can't be used for openSUSE versions that have different
background.
The 11.0 is not finished development of 10.1, 10.2, 10.3 series, it is
rather that each version has completely stand alone development that has
nothing common with previous versions, or plans for the future.

Maybe it had meaning once, long time ago, but from version 5.3 until now I
couldn't see any connections.

--
Regards, Rajko
http://news.opensuse.org/category/people-of-opensuse/

[TaraIkeda]

There are other versioning schemes that are confusing too, look at Ubuntu for example its a good version scheme but it can still confuse the new user.
OpenSuse has a confusing scheme too it seems.
Personally I think the best naming scheme goes to Ubuntu though, .06/04 and .10 often indicate the months they were made in.
04 for April and 10 for October.
Then there is the number in full, 8.04 indicates the year 2008 and the month it was released (April)*
For OpenSuse there is actually a more true version scheme, OpenSuse 11.1 is the 11th release series of Suse and .1 probably indicates revision number (makes sense)
But OpenSuse 11.1 is technically about version 20 or 30 something, numerically speaking never did the math though.

*Please note that there was Ubuntu 6.06, Ubuntu Dapper was released late on purpose to ring out bugs.

[dragonbite]

Google helps confuse things by distributing so much as "beta" even though it becomes mainstream and people start really relying on it (despite warnings).