When will 0.3.15 release?

[vicmarcal]

2)From PR point of view II: Dates are the worst things that can be used in a versioning system. I have seen countries with YY/MM/DD and YY/DD/MM.

While I generally support and agree with the rest of your points, here I want to emphasize that there's an ISO standard for writing dates. 2012-03-19. It has two advantages - nobody from EU can mistake it for US date and vice versa & filenames using it sort as you would expect.

Yeah, I know there is an ISO standard
But real life says that people is used to what their culture and language teachs them. Unless someone knows about this ISO,an engineer mainly, people will interpret the date as his culture interprets. Anyway, from the argumentary this point is one of the less important compared to the others(proper "Beta" definition, less motivational, less PRing,etc..)

[jonaspm]

having a date for releases has some advantages and disadvantages, for example,

if you have just released the new version, everyone will shout "OH! A RECENT RELEASE, THE PROJECT IS ALIVE AND DOING WELL!"

but if you haven't released a new version for a year (like currently ReactOS is) then people would hesitate if the project is still alive or not, unless they search the forums or JIRA.

I think that number versioning is better but thats my personal POV

[BlackRabbit]

but if you haven't released a new version for a year (like currently ReactOS is) then people would hesitate if the project is still alive or not

The key word here is people. Are we talking about the general public, or developers? If we are talking about the general public, it makes far more sense to use ISO-date-version, because a number-version is meaningless to the general public. In fact, it is meaningless even to some (new) developers. But a version such as 2013.07.01 at least provides an indication of when the version was released.

This thread hints at something else that I have been thinking for a while, which I will illustrate with a principle:

In the USA, entrepreneurs and venture capitalist call it the Sausage Factory Principle:

Many people like sausage. Few people want to know how it is made.

As software developers, we must keep in mind that we are delivering a product. Our primary concern should be the quality of that product, as perceived by the end-user. I used this principle when I was trying to do Visual Studio integration, for example. My product was a Visual Studio build hierarchy. My customer was any software engineer who wants to contribute to ReactOS and would prefer to use Visual Studio. My sentimental disposition regarding this matter was simple: If, after I created the product, my customer found it to be sub-standard, then I would fix it. My relationship with my customer is through my product. If my product is good, my relationship is good. If my product is bad, then my relationship is bad. Not once do I ever expect credit with my customer for making a good effort, and I certainly do not want my customer to participate in my development of the product any more than I want to help my butcher make sausage.

Here, we are discussing something that is meaningful only outside the context of core ReactOS developers. If you are thinking about the journalists who occasionally write about ReactOS, I can assure you: Not one of those journalists has in his mind that ReactOS is currently at 0.3.0, or whatever. There are simply too many projects that they write about to maintain such minutiae in their minds.

What we are discussing is a something that will benefit the perception of ReactOS. It would benefit the general-user-population (which is already essentially non-existent), and it would benefit the morale and clarity of non-core developers. The only people, in my mind, who would not be benefited, are people for whom 0.3.0 has sentimental historical significance.

[hbelusca]

2)From PR point of view II: Dates are the worst things that can be used in a versioning system. I have seen countries with YY/MM/DD and YY/DD/MM.

While I generally support and agree with the rest of your points, here I want to emphasize that there's an ISO standard for writing dates. 2012-03-19. It has two advantages - nobody from EU can mistake it for US date and vice versa & filenames using it sort as you would expect.

In France, we use DD/MM/YY

[vicmarcal]

The key word here is people. Are we talking about the general public, or developers?

Both.
Is Linux community made by General people or Developers?Both.
Since my arrival to ReactOS I've tried to push the idea that ReactOS Community is not just ReactOS devs. When I arrived, 4 years ago or so, ReactOS Project was mainly Developer-centrical. There was a huge gap and connection problems between the ReactOS Development Team and the ReactOS Forum(Users and Fans). But slowly the Developer-centrical mind has become much more open, the information now flows bidirectionally(ReactOS Meeting Minutes, Epic Wins, Testing requests, Twitter, Facebook, etc...). Still there is too much work to be done in this direction(we all know) but thanks to this, really cool projects have began to appear from non-ReactOS devs: Guys designing booklets and ReactOS Themes, Gyros made a nice MSPaint, Naums is working in a ReactOS Updater, several testers helps in Testing calls, others testing Epic Wins, and lot of people sharing new cool apps/features/suggestions...All of this creates a big big value around the Coding area. Hbelusca was a forum guy, one "General people" member of this Community, that moved to serious development iirc. So General People is a pool of potential Developers, and if not..they are a pool of pure motivation and prescriptors.
A Release is the most direct way of communication between ReactOS Project and any user who wanna use it.Even if he just tests it in a casual/lets-see-what's-this way.

Do we want to attract Devs? Sure.
ReactOS without Devs is nothing.But ReactOS without Translators, Designers, Testers, Contributors, Debuggers, Analyzers, Connectors, PR guys, HTML/DRUPAL developers, even Donnors(donnors of time, money, whatever) is nothing too.
So yes, Releases are not just Developer oriented but General Public oriented too because we have to create a Great Community and right now we are just a Great-but-small Community.

[BlackRabbit]

ReactOS without Translators, Designers, Testers, Contributors, Debuggers, Analyzers, Connectors, PR guys, HTML/DRUPAL developers

I called these people developers when perhaps I should have calling them contributors. In any case, I think this whole question of whether to use x.x.x version scheme versus ISO yyyy-mm-dd version scheme is more a matter of psychological/psycho-emotional preference. A new developer, joining in April of 2013, for example, would find the version 0.4.0 meaningless. S/he might infer that, since 0.4.0 is not a whole number, ReactOS is not stable enough to be beta-quality, but that is indeterminate. In other words, to an outsider, x.x.x has no significance.

I have a feeling that, for ReactOS insiders, there is psycho-logical, and perhaps psycho-emotional significance.

What I am saying is that, to those people who are not initiated to ReactOS, the ISO format has more meaning than the x.x.x format. The ISO format also conveys a sense of progress, whereas the x.x.x format does not. So, objectively speaking, it would seem that the ISO format has greater benefit to the majority of observers. The only people I can see the ISO format not benefiting are the people who are already heavily invested. But those people are not the customers. They are the servers of the customers.

This thread vaguely hints at another topic that is quite important, which is actually related to my attempt at Visual Studio integration, and that is the matter of objectivity.

I use both Linux and Windows equally. In fact, have 7 years more experience with Linux/Unix than with Windows, but from my posts, you would think that I hate Linux. That is because, when I approach any problem/situation, I put myself into the shoes of my client/customer. I asks myself, "What are the needs of my client?" For ReactOS, I wanted to give the best Visual Studio experience possible, because I sympathize with the perception of the majority of Visual Studio developers. That is why I tried to eliminate the cmake step. If ReactOS were a Linux clone, and GNU were the primary tool-chain, and there just happened to be a minority group of people who were hard-core Windows developers, and as such, they had managed to infuse Visual Studio into the Linux GNU tool-chain such that, upon typing "make", a dialog-box briefly popped up, where the developer had to type something in then click OK to continue, I would be just as diligent in eliminating it, because we all know that, as simple and "painless" as this step is, it would be a great nuisance to a Linux programmer who is not accustomed to seeing such a thing during a make.

In the case of version scheme, we should ask, "Who, really, is the customer?" ReactOS contributors? Or the general public? I think it is the general public. Then, we might ask, "From the customer's point of view, which method gives most benefit to ReactOS?" I think it is ISO, not x.x.x. The latter has no meaning to this customer. The former does.

[fred02]

Dont expect guys out of coding knows what does it mean."ReactOS moves from 2013.6.3.to 2013.10 ! ": the Marketing guy would kill ya.

Totally agree with that.
I would even say that all this date based versioning is a nonsense. Other have done their home work before us, and there is no VS 2012.2.1, MS Office 2013.1.29 or Windows Server 2012.9.4. Oh, and they keep the "real" versioning inside: 11.x.x, 15.x.x, 6.2.xxxx.
Yes, some Linux distribitions use that scheme, but, as many have pointed out, they are "stable". Also, (GNU)/Linux is a compilation, rather than a monolithic product, so versioning is totally arbitrary and the notion of a "bundle" created on YYYY.MM.(DD) is just as appropriate.

2)From PR point of view II: Dates are the worst things that can be used in a versioning system. I have seen countries with YY/MM/DD and YY/DD/MM.

IFAIK Japan uses the first one.

A new developer, joining in April of 2013, for example, would find the version 0.4.0 meaningless. S/he might infer that, since 0.4.0 is not a whole number, ReactOS is not stable enough to be beta-quality, but that is indeterminate. In other words, to an outsider, x.x.x has no significance.

I have a feeling that, for ReactOS insiders, there is psycho-logical, and perhaps psycho-emotional significance.

What I am saying is that, to those people who are not initiated to ReactOS, the ISO format has more meaning than the x.x.x format. The ISO format also conveys a sense of progress, whereas the x.x.x format does not. So, objectively speaking, it would seem that the ISO format has greater benefit to the majority of observers.

To me there two parts of this. I agree that for a passer-by YYYY.MM.DD will indeed suggest "up to dateness" and maintenance, but let not forget the backslash of having a 2 years old version as stable. I would not say I convey a sense of progress, since it means looking at at least two "version strings" and here quickly changing x.y.z would do the same, and more, if the first digit is incremented.
On the other hand I don't see how the YYYY.MM.DD is more informative a new developer. It convey nothing. Is it stable? No idea. Is it feature-complete? Dunno. Is it maintained? Maybe, if the date is not to old. As you said yourself with 0.y.z at least it can be inferred that the project is not production ready and is probably half-working. As for the date of the latest release, it is probably next to the download link. After that one have to roll up the sleeves and see for himself.
But the bottom line that beyond the initial glance at the product all versioning is meaningless. People used OpenSSL for more than a decade in mission critical settings while it has not reached v1.0. DOSBox is used for many commercial products, while it is "only" 0.74.
On the other hand look at this Chrome/FireFox version-pee contest. Is v19 as stable and feature complete as 18? Then why every time the new version is out there is a critical security patch a week or two later (at least with FF)? And what are the significant new features between the two versions (Ok, for FF19 it is easy: there is a buggy PDF viewer activated by default that can't be disabled from the UI )?

[Black_Fox]

I have one final suggestion, that will look very un-mainstream. If ROS team wants to attract more testers, they can just number the stable(?) releases as is (0.3.26), while the release builds can be numbered like 2013.03.20.58557. It's on the decision of others whether is the revision number sufficiently visible and whether is the version string too long or not.

[Aeneas]

A question on the matter:

Have we got any expectations? Like, "release till June" or "release within 2013" or "the day after tomorrow"? I mean, anything relating to time and not just to "we have to do X, we have to do Y" (as that is not the question)? - If not, is there an idea when this will be known?

(Yes, I want another release; I know there are nightly builds, but for all I hear, they are of worse quality than a release.)

[fred02]

I have one final suggestion, that will look very un-mainstream.

Actually not that much. It makes me think about the convention Microsoft use. May be we can do it too.

[Black_Fox]

I know there are nightly builds, but for all I hear, they are of worse quality than a release.

This is very arguable. In nightly builds there is not a desktop wallpaper included and there are also some hacks applied on each release, but recent nightlies >> 0.3.14.
In other words, nightly builds are definitely better than last release, but if there was a release made from today's nightly build, it would be probably perceived as a tiny bit better than the nightly build itself.

[erkinalp]

I support Ubuntu-like versioning if we achieve a regular scheduling of releases like e.g.ROS 13.03 for current month's release. Code::Blocks also makes use of this versioning system.

[DOSGuy]

I also support that, once we hit 1.0. ReactOS 13.03 or ReactOS 2013 suggest a finished product.

[BlackRabbit]

Have we got any expectations? Like, "release till June" or "release within 2013" or "the day after tomorrow"? I mean, anything relating to time and not just to "we have to do X, we have to do Y" (as that is not the question)? - If not, is there an idea when this will be known?

I don't know of course. I do believe that there should be periodic beta releases, because it induces developers to be mindful of the importance of stability. A product can be stable without being complete. For example, let's say that some applications break because they need the crypto API that does not exist. In my mind, this situation is not bad at all. It is far better than actually having a crypto API, but the machine BSOD's constantly because certain subsystems are too buggy. The way to scale up a project like ReactOS is to leverage the large number of contributors, which each of them exercising individual discipline, and understanding that stability is the foundation of scalability. Instability, by contrast, blocks the ability of a large number of developers to contribute effectively. Releasing more frequently would remind developers of this fact.

Our disposition should be:

This is what we have now. It is incomplete. But at least what we have will not blow up in your face.

Our disposition should not be:

This is what we have now. It has a ton of code. Yeah, a lot of it is very buggy, but you get the idea. Someday, the bugs will be taken out, and you will really enjoy it. We hope you enjoy it now!

There is use for having a semi-stable, 50%-complete OS. There is no use for having an unstable, 95%-complete OS.

The ISO-date format affirms the notion that the OS will not be complete any time in the near future, and that some usability is an objective, and it allows us to remain-in-the-land-of-alpha-versions until there is consensus that a beta version is due. It can be declared, for example, that 2013.09 is the next beta release. Meanwhile, alpha versions such as 2013.04.15, 2013.05.02 and 2013.10.31 would continue. The notion that 2013.10.31 is bad for the general public is false. The general public would not care, because the general public would not know, because not one of us would tell the general public:

"Hey, we have an alpha version of ReactOS that we would like to confuse you into thinking that it is beta. Here, try it."

The general public only knows what we tell them. If we tell them that there are no gamma releases available, then there are no gamma releases available. If we tell them that there are no beta releases available, then there are not beta releases available. The only way the general public would become confused that ReactOS is a "finished product" as some of you have said, is for us to convey it as such. Fortunately, someone had the sense to make this clear to the general public:

ReactOS 0.3.14 is still in alpha stage, meaning it is not feature-complete and is recommended only for evaluation and testing purposes.

The preceding statement is very clear to me. But without it, I would not have known that ReactOS is purely alpha software. Now I know, because I was told.

On the other hand I don't see how the YYYY.MM.DD is more informative a new developer. It convey nothing. Is it stable? No idea. Is it feature-complete? Dunno. Is it maintained? Maybe, if the date is not to old. As you said yourself with 0.y.z at least it can be inferred that the project is not production ready and is probably half-working. As for the date of the latest release, it is probably next to the download link. After that one have to roll up the sleeves and see for himself

The version 0.y.z is meaningless to me. The only reason that I know that this version number has been used because ReactOS is not yet stable is because I read/heard somewhere the the version bumber has been used because ReactOS is unstable. I remember seeing some very stable software that had sub-1 version numbers. [I cannot remember where.] I also know of (> 1) version software that is horribly unstable.

What matters is what we proclaim, in writing, so that it is clear, just as was done on the ReactOS home page.

[DOSGuy]

The version 0.y.z is meaningless to me. The only reason that I know that this version number has been used because ReactOS is not yet stable is because I read/heard somewhere the the version bumber has been used because ReactOS is unstable. I remember seeing some very stable software that had sub-1 version numbers. [I cannot remember where.] I also know of (> 1) version software that is horribly unstable.

Not stability, completeness. Version 0.1 of a program might be totally stable, but it only does a tiny fraction of what the developer wants it to do. Version 1.2 might be buggy as hell, but it achieved all of the developer's original goals (v1.0) and has added additional features as well. Once you hit 1.0, you can do a Linux-style numbering system where even point releases (1.2, 1.4, 1.6) are stable and odd point releases (1.1, 1.3, 1.5) are beta. You can name the version after the year of release (MyProg 2012, MyProg 2013) and use commit numbers or the word "beta" to denote your developmental builds. You can name your versions after the date of release (MyProg 13.03 for March 2013), again using commit numbers or "beta" to denote your developmental builds. Once you hit 1.0, the sky is the limit! But until then, any version number that doesn't start with 0 creates a false impression that your program is "complete" from the perspective of meeting its original goals. It's been that way for decades; most people don't need to be told that v0.3 is going to be either alpha or beta software. A 0.x version number tells you nothing about whether it's alpha or beta -- the distinction between those states is usually whether testing is internal or external -- but they'll certainly know that it isn't gamma.