New version scheme

[DOSGuy]

Aleksey Bragin proposed dropping the current version scheme of X.Y.Z for future releases. No one objected to the proposal. Ziliang Guo suggested an alternative based on month and year of release plus an additional code name to indicate NT compatibility target.

That makes no sense for an alpha-stage product. If you release a 12.09 like Ubuntu or AMD drivers, it suggests a finished project. Even if you call it 12.09 alpha, it suggests that there will quickly be a 12.09 beta and then 12.09 final/gold by the end of the month. It's fine to do this after "1.0", but until then, 0.3/0.4/0.5 gives potential users an idea of the completeness of the product. There's no other way to say it than that a month and year version system is a terrible idea that will fool and disappoint a lot of people.

[Dave3434]

thanks dosguy i was wondering the same thing? why follow ubuntu release scheme?

[Z98]

The reasoning behind this move is fairly straightforward. Internally to the developers, the version numbers don't mean anything. The moment a versioned release is made, that version is out of date (in fact it's out of date before we even release). It also became a point of fixation for the community wherein they associate the progress of the project with a completely arbitrary number, and to be frank, it really is arbitrary. There's literally nothing stopping me from spinning a new release tomorrow as 0.4.0 instead of a 0.3.16 since neither one holds any significant meaning internally. The community has however consistently felt otherwise and that fixation has caused considerable irritation internally. At the same time, attempts to provide even a modicum of meaning to the version numbers internally haven't met with any real success. So since we have never been able to actually internally ascribe meaning to these version numbers and continuing their use results in the wider community making invalid assumptions, we have no motivation for their continued use.

[SomeGuy]

This sounds like a good idea to me. There are unfortunately production quality projects that use "0.x.y", that opens the ReactOS version number to mis-interpretation.

Although I would suggest a scheme that is intentionally a bit terse and does not raise any OTHER expectations. Something like "13.09" could quickly get equated with progress of Ubuntu or similar, and might still be interpreted as implying potential production quality. Perhaps something like "Alpha 09022013.0" or "Alpha Rev 59969-stable-release".

Actually, using the build number would have the advantage that a release might not start to look "old" as quick since it does not directly reflect the date, and is less memorable than a "x.y.z" version. It would also make it a little less jarring when someone testing a stable release build is instructed to test a nightly. (And it has the advantage of upping Firefox/Chrome etc. rapid release numbers by a few thousand )

[Dave3434]

i think it's a bad idea upgrading from one version to another will just cause problems since it could break things. look at ubuntu now it's bloated slow and full of bugs.

[Z98]

That has absolutely no relevance to the current topic.

[Dave3434]

i just think it's a bad idea.

[mrugiero]

i think it's a bad idea upgrading from one version to another will just cause problems since it could break things. look at ubuntu now it's bloated slow and full of bugs.

¿?

Changing the way versions are called doesn't change in the most tiny bit the bloatedness and bugginess of the software. Ubuntu might use x.yy.zz versions and still be just as slow and buggy.

[EmuandCo]

I am all for it. This makes it possible to release subversions faster, like every month. No "When will Version 0.4.X be released??" and stuff.

[Black_Fox]

I'm very comfortable with the yy.mm version scheme, with the "Alpha yy.mm.rrrrr" (r = revision) being the full version string even more comfortable.

[Aeneas]

There's literally nothing stopping me from spinning a new release tomorrow as 0.4.0 instead of a 0.3.16 since neither one holds any significant meaning internally.

BREAKING NEWS: Z98 ANNOUNCES RELEASE 4.0 FOR TOMORROW!

(It was just too hard to resist...)

[PurpleGurl]

That sounds like what the gossip magazines and paparazzi do. They take things out of context to build sensation.

I am not sure I like the new scheme, but the devs will do what they want, and they tend to know what is best. It would be nice if they could give exact numbers for exact features, but the way the development works, it is not practical. There are too many variables. We cannot control what WINE does, when developers awaken with sudden brainstorms, how many people donate, or really what the developers decide to work on.

[eersoy93]

http://www.reactos.org/forum/viewtopic.php?f=9&t=12789

In spite of I opened first related changing the version scheme, why didn't anybody post to this topic except gonzoMD?

[ImperialSpectre]

Why not just make ReactOS into a rolling-release model then it can be updated constantly with the stable improvements - or is that only a linux thing.

[mrugiero]

Why not just make ReactOS into a rolling-release model then it can be updated constantly with the stable improvements - or is that only a linux thing.

You already have a rolling release: the nightlies.