New version scheme

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

User avatar
jonaspm
Posts: 585
Joined: Mon Nov 21, 2011 1:10 am
Location: Mexico
Contact:

Re: New version scheme

Post by jonaspm »

I think that it would be better a version scheme based on revision, for example:
59980
THEN
5.99.80 or 5.9980
BlackRabbit
Posts: 128
Joined: Sat Dec 22, 2012 7:36 am

Re: New version scheme

Post by BlackRabbit »

I proposed the date-based scheme, as have others, several times, previously, and it was rejected.

I think there is something more fundamental going on here that I would like to mention by way of anecdote:

A few years back, there was a discussion (argument) in a C++ programming group about which is better: balanced or unbalanced curly braces.

Here is some code for unbalanced:

Code: Select all

int main ()
{
	while (true) {
		;
	}
	return 0;
}
Here is the same code for balanced:

Code: Select all

int main ()
{
	while (true) 
	{
		;
	}
	return 0;
}
Most C programmers choose between these two styles. A small, insignificant percentage of people use a hybrid style that is not worth mentioning.

As the argument raged about which is better, I watched very closely, not at the content of their arguments, but who, was doing the arguing, and what side they were arguing for. I noticed very strong correlations among members of the same curly-brace group, meaning that, on other subjects:
  • whether monomorphic or polymorphic types are better
  • exception handling
  • multi-threading and synchronization (lock-free programming)
  • functional programming
  • whether Java is truly portable or it only runs on one machine, the JVM
  • whether garbage collection is desirable in a language like C++
  • etc.
...essentially, on a wide range of topics, the members of each group, balanced or unbalanced, were correlated in their determinations of what is right and what is wrong. In other words, if each of the above topics were the linearized component of a vector, the vectors of members of one group would very strongly project onto each other, and would not project strongly onto the vectors of members of the opposing group - the individual topics and preferences within a group WERE NOT INDEPENDENT! If it really is true that perception is based on rational thought, and that most of the people arguing all possess roughly the same intellect, then those vectors should have been uncorrelated, meaning that sometimes a person is right, and sometimes a person is wrong, and being right or wrong has nothing to do with genetic predisposition.

Looking at this version thing, I feel that we have the same situation. No matter how much so-called rational argument is supplied, some people will never be convinced by the opposing side because they are inherently predisposed to their current perspective.

Recognizing this situation, when it arises, allows one to avoid quite a bit of frustration by refraining from attempting to convince anyone of anything.
DOSGuy
Posts: 582
Joined: Wed Sep 14, 2011 5:55 pm
Contact:

Re: New version scheme

Post by DOSGuy »

Z98 wrote:The reasoning behind this move is fairly straightforward. Internally to the developers, the version numbers don't mean anything. ... 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.
And yet a decision was made to call the latest release 0.3.15 instead of 0.4.0 because there were too many regressions to justify a minor release bump (or whatever the reason was). It must mean something to someone if there was objection to calling it 0.4.0.

I certainly sympathize with the developers having to hear "when is 0.4.0 going to come out?". I certainly recognize that the "when is 0.5 going to come out?" questions will start the second that 0.4.0 is released. I don't suppose there's ever been an open source project (or a closed source project that had a forum) that didn't have that problem -- especially if development took years -- but I truly do sympathize with the devs who have to put up with seemingly ungrateful people demanding faster progress. That said, it just doesn't seem to be true that the version numbers don't mean anything. ReactOS works pretty well, but it deserves to be considered alpha, so it should have a version number that suggests an alpha level of development like 0.3 or 0.4. When it gets to a point that ROS can safely be used by people who understand the risks of beta testing, it should have a version number that suggests a beta level of development like 0.5-0.9. When it gets to a point that there is a stable version suitable for everyday use, then you can use any system you want. You could:

Go the Linux kernel route, using even numbers as production versions and odd numbers as unstable/beta releases (i.e. 1.0 is stable, 1.1 is the unstable version of the future 1.2 stable version). You can use a year-month model like Ubuntu, with 13.09 being the stable release from September 2013, while the unstable versions can be called 13.xx alpha/beta/release candidate/"danger Will Robinson!!!". Or you can use the boring old system where a bump of 1 is a major release, .1 is a minor release, and .01 or .0.1 is a very minor release. At that point, do whatever you want. But if you give an alpha stage program any version number that doesn't start with "0.", you suggest a level of safety and stability that ROS doesn't have.

Now, of course, you could do "0.13.09" for the September 2013 release, "0.13.10" for October 2013, etc., and that would safely convey the message that the product is not considered to be of production quality yet. That would suffice, but it doesn't tell you anything about it being alpha or beta. You could call it "0.13.10 alpha", but that could fool people into thinking that "0.13.10 beta" is just around the corner. The existing model of 0.1-0.4 = alpha, 0.5-0.9 = beta is instantly obvious to people and requires no further explanation. It may unfairly make it look like the project is progressing slowly, but it accurately portrays the OS as alpha stage, and complaints about slow progress are bound to be levelled when any project has been in development for 15 years!

Now, I think that ROS could fairly and accurately call itself 0.4.x by now, and I certainly hope that the next release is called 0.4.0. I also get the impression (rightly or wrongly) that recent progress on the kernel and memory manager are likely to allow much faster progress towards a usable explorer_new and much broader software compatibility. After 15+ years getting to 0.4, it looks like ROS will progress through 0.5-0.6-0.7-0.8-0.9 (or maybe even skip directly to 0.9 from 0.4/0.5) in a fraction of the time. Is there something wrong if a project spends 15 years getting to 0.4 and then only 1 year (for instance) going from 0.5 to 1.0? No, if it was legitimately too unsafe to be considered beta for 15 years, and then reached a stability milestone that allowed it to progress from beta to production in 1 year. ROS is an OS, which means that it has to really work before you can declare it anything other than alpha. That may disappoint the developers who have to answer obnoxious questions about being at 0.3.15/0.4.0 after 15 years, or being in 0.3.x for 7 years. Eliminating the x.y.z version scheme and just using a commit number like 59995 would stop the "when is version x coming out?" questions, and that might be best for the developers, but it wouldn't be best for the users. The version number should make it obvious that ROS is alpha, and 0.3.15/0.4.0 does that. The users can be a pain sometimes, but so is installing an OS that you think is safe to use and losing all of your data!

It sure looks to me like the beta stage of ROS will be a lot shorter than the alpha stage, and then you can all bask in the praise you receive for so quickly moving through 0.5-0.6-0.7-0.8-0.9 (relatively speaking). At that point, the version system that led to so many complaints during the alpha stage will lead to congratulations during the beta stage. Will it falsely and unfairly create the impression that more work was being done during the beta stage than during the alpha stage? You betcha!™ (Sending $5 to Sarah Palin.) But whether the version number creates an accurate impression of progress and effort or not, it does create an accurate impression of the safety of installing ReactOS and the stability and compatibility that one should expect once it's installed. Surely that's important enough to put up with a few n00bs asking questions that are usually answered satisfactorily by the dedicated fans on this forum. Maybe they also PM or email their uneducated and unreasonable progress demands. I'm sorry if that's the case. I hope that those voices are overshadowed by people who recognize the amazing thing that you're doing and say so in the forum on a regular basis.

The current model just makes more sense to people. It would be sad to think that it was being abandoned for a system that's less obvious and more likely to create confusion and frustration because of the "when is 0.x going to be released" threads.
Today entirely the maniac there is no excuse with the article. Get free DOS, Windows and OS/2 games at RGB Classic Games.
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Re: New version scheme

Post by Z98 »

And there's the rub. ReactOS does not have users, not in the sense of conventional desktop users. Conservatively speaking, it won't be until ReactOS enters the beta stage that we can expect any measurable number of users.

One thing that I want to point out is, this debate can easily go down a rabbit's hole regarding the entire release tempo. If we do go down that route, I want people to be aware that one of the options on the table, and one that could very well win, is to completely forgo 0.3.x or 0.4.x point releases and only do 0.x releases, with the associated time gap in between releases.
MadWolf
Posts: 577
Joined: Sat Dec 31, 2005 4:19 am
Contact:

Re: New version scheme

Post by MadWolf »

hi
this may sound a bit harsh but if anyone post a when is 0.00 getting released then thay get 3 warnings and the topic is locked and after the third warning then they get a temp ban and if they post a when is 0.00 getting released then thay get a permanent ban this may stop when is 0.00 getting released
oldman
Posts: 1156
Joined: Sun Dec 20, 2009 1:23 pm

Re: New version scheme

Post by oldman »

Post by DOSGuy » 06 Sep 2013 21:03
Eliminating the x.y.z version scheme and just using a commit number like 59995 would stop the "when is version x coming out?"
This is much the same as my thoughts.
My suggestion would be, to just take a revision from trunk, debug it as with normal releases, and name it Snapshot Rxxxxx, where xxxxx is the revision number that was used. Then when it gets stable enough to be called beta, then start using a numbering system.
Please keep the Windows classic (9x/2000) look and feel.
The layman's guides to - debugging - bug reporting - compiling - ISO remaster.
They may help you with a problem, so do have a look at them.
wildschwein
Posts: 416
Joined: Tue Sep 16, 2008 1:13 pm

Re: New version scheme

Post by wildschwein »

my opinion:

leave things like they are - community and fans are used to.
When it's time for 0.4 then it's time for it.
When it's time for 0.5 then it's time for it.

:-)
Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 2 guests