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.