Version Number Spring Cleaning
<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the categories: Engine, Practices, Releases, Version 1.9.</i>
Since Yagisan brought it up, let's discuss our version numbering. The current scheme is a bit complex, and since the beginning of the 1.9.0-betaX releases our plans have shifted focus somewhat. I propose a revamp of the numbering along the following lines:
<ul>
<li>The "beta" suffix will be removed in favor of calling the entire 1.9 series a beta series. In fact, we might try the Linux way of doing unstable development in odd-numbered versions and keeping the even-numbered versions stable and as bug-free as possible.
<li>Considering the scope of all the changes we have already done and will be doing (like the networking things), we should call the next stable release 2.0.
<li>The separate version numbers for the plugins distributed with the engine (games, etc.) feel unnecessary to me. They should use the same version number as the engine. (It's always been a bother to increment all the different version numbers in a sane way.)
</ul>
This would mean the following reassigning of the versions:
<ul>
<li> 1.9.0-beta1 → 1.9.0
<li> 1.9.0-beta2 → 1.9.1
<li> 1.9.0-beta5 → 1.9.4
<li> 1.9.0-beta5.1 → 1.9.5 (keeping it simple)
<li> 1.9.0-beta6 → 1.9.6
<li> 1.9.0-beta6.1 → 1.9.7
<li> 1.9.0-beta7 → 1.9.8
<li> etc.
</ul>
So it would always be (major).(minor).(rev), with the (rev) being incremented for each release regardless if it's just a patch or something bigger.
In the repository this would mean that the 1.9.0-beta6 branch becomes /branches/1.9.6. Out of that may actually come 1.9.7, 1.9.8, etc., until we branch out a new release branch from the trunk. The release branches should always be in a releasable state so we can do the monthly updates.
How does this sound?
Since Yagisan brought it up, let's discuss our version numbering. The current scheme is a bit complex, and since the beginning of the 1.9.0-betaX releases our plans have shifted focus somewhat. I propose a revamp of the numbering along the following lines:
<ul>
<li>The "beta" suffix will be removed in favor of calling the entire 1.9 series a beta series. In fact, we might try the Linux way of doing unstable development in odd-numbered versions and keeping the even-numbered versions stable and as bug-free as possible.
<li>Considering the scope of all the changes we have already done and will be doing (like the networking things), we should call the next stable release 2.0.
<li>The separate version numbers for the plugins distributed with the engine (games, etc.) feel unnecessary to me. They should use the same version number as the engine. (It's always been a bother to increment all the different version numbers in a sane way.)
</ul>
This would mean the following reassigning of the versions:
<ul>
<li> 1.9.0-beta1 → 1.9.0
<li> 1.9.0-beta2 → 1.9.1
<li> 1.9.0-beta5 → 1.9.4
<li> 1.9.0-beta5.1 → 1.9.5 (keeping it simple)
<li> 1.9.0-beta6 → 1.9.6
<li> 1.9.0-beta6.1 → 1.9.7
<li> 1.9.0-beta7 → 1.9.8
<li> etc.
</ul>
So it would always be (major).(minor).(rev), with the (rev) being incremented for each release regardless if it's just a patch or something bigger.
In the repository this would mean that the 1.9.0-beta6 branch becomes /branches/1.9.6. Out of that may actually come 1.9.7, 1.9.8, etc., until we branch out a new release branch from the trunk. The release branches should always be in a releasable state so we can do the monthly updates.
How does this sound?
Comments
However I do agree that continuing on with releases made under the name of 1.9.0-betaX is becoming a bit, well, silly? We've been in beta for 3(?) years now. I guess another question we should be asking is;
Is current svn still beta-grade?
Unfortunately, I have to answer an honest "yes" to that question. I feel that to suddenly drop the beta suffix would be rather misleading and possibly, disingenuous.
Personally I feel I know where I am with software that wears its state on it's sleeve so-to-speak and that means a naming scheme that doesn't assume knowledge of Linux naming practices.
<blockquote cite="#commentbody-3381">
<strong><a href="#comment-3381" rel="nofollow"> skyjake</a> :</strong>
<p>And BTW, does the blog post email notification thing work any more? I don?t recall seeing any notifications about recently made posts.</p>
</blockquote>
Seems like its broken. I've not had any either. However, I have had a few notifications for new thread subscriptions.
we have been making peopel download the betas as a main release (for all the betas now?) because 1.8.6 did not have snowberry with it. so I don't see much difference in them downloading an odd numbered build. it's not like they are downloading svn's
having the stable release as 2.0 is also a good idea because deng has gone through so many changes since 1.8.6
The term "beta" hasn't really been used in its commonly accepted meaning anyway in Doomday. Here it actually means "unstable", as in "under development".
I think the odd/even thing is nice because we can avoid all the complicated suffixes. It's a much more logical system than what Doomsday has used in the past (and there has actually been a couple of version numbering scheme changes over the years).
Since I found out about this convention I have asked roughly a dozen other people whether they had a) heard of it and understood what is implied by those numbers and b) if it is more helpful to have a version naming scheme along the lines of that which Doomsday currently uses. Every response I was given indicated the latter. Granted, this is hardly an exhaustive or scientific study but these were "real-world" computer users and/or gamers.
I do agree though that we aren't exactly using the beta term correctly but I don't see that as a reason to drop the scheme entirely.
In my opinion it would be a whole lot more logical if we were to now jump from 1.9.0-beta6.1 straight to 2.0-alpha1
I would personally like to get rid of the suffixes, but I can't say that they wouldn't be informative.
Going to 2.0-alpha1 doesn't solve the issue of what to call the patch releases without adding to the bloat.
I can live with declaring a "stable" version (1.8.6) and also declare a "development" version (1.9.0) and mark them up as such everywhere they are downloadable from. However, I really do think that having descriptive terms like "alpha/beta/whatever" in the version name is understood by a great many more people.
<blockquote><p>we?re already having minor version numbers in our suffixes: ?beta6.1 ?</p></blockquote>We'd still have the same problem but further to the left in the version name. The only reason we couldn't call it beta7 is because we've already announced plans for that version.
I must state that I personally prefer version names that are informative and if necessary, perhaps "bloated".
Version naming is actually pretty important on many levels, not least that it gives us another method to strengthen our brand image. Do we go with a naming scheme that Average Joe understands, or a non obvious convention that will be lost on most people?
Doomsday is already perceived (in the DOOM community) as being rather unfriendly to average users, from our many disparate websites to the engine + plugins design (most still refer to the whole as "JDoom"), to our "FlightSim-cockpit-like" control panel and "over-use of technical jargon" throughout.
You could argue that I'm looking at this too deeply but I really do think this kind of thing matters a great deal.
This would mean that Beta6.1 would actually be 1.9.7-alpha. (I think "alpha" should be preferred until we stop adding big new features and move to fix-for-stable mode).
There is the practical issue of how would we refer to upcoming releases? If we do monthly releases, it's difficult to determine the release number for a bigger feature whose completion may take an indeterminate amount of time.
<blockquote>Doomsday is already perceived (in the DOOM community) as being rather unfriendly to average users, from our many disparate websites to the engine + plugins design (most still refer to the whole as ?JDoom?), to our ?FlightSim-cockpit-like? control panel and ?over-use of technical jargon? throughout.</blockquote> We do have some huge usability issues, I agree. Fortunately we also have plans for fixing some of those. In the big picture, the version numbering is quite a small detail, I think. As long as the numbers get bigger, people should be happy.
<blockquote><p>There is the practical issue of how would we refer to upcoming releases? If we do monthly releases, it?s difficult to determine the release number for a bigger feature whose completion may take an indeterminate amount of time.</p></blockquote>I think we really only have one option and that is to change our version numbering to a four-place scheme like that used by Microsoft and (recently) Linux; (major).(minor).(minor).(rev) so:
1.9.7.0-alpha > 1.9.7.1-alpha > 2.0.0.0
With the convention of triming trailing zeros when written.
(1).(9).(0-beta6).(1)
I would agree to using the fourth place for emergency/out-of-cycle updates, but the normal releases should only increment the third place (the rev). (Assuming we'll go into the monthly cycle, which would be very good.)
<blockquote>IF we go for the compromise I suggest using 1.9.7-unstable or 1.9.7-development. because using 1.9.7-alpha will get people to expect a 1.9.7 release and when 1.9.8-alpha comes out peopel would be like wtf?!?</blockquote> I think that's a valid point. However, if we use "beta" we should also use "alpha" instead of "devel"/etc. for consistency. What if we actually used a prefix:
alpha-1.9.7
alpha-1.9.8
Doomsday Engine alpha-1.9.8
Doomsday Engine beta-1.9.20
Doomsday Engine 2.0.0
<blockquote>In fact, we might try the Linux way of doing unstable development in odd-numbered versions and keeping the even-numbered versions stable and as bug-free as possible. </blockquote>
Except that Linux has abandoned the odd/even scheme long ago (as of March 03 2005).
<blockquote>Currently we already have essentially a four-place scheme:
(1).(9).(0-beta6).(1) </blockquote>
Packager speaking here. That is essentially a six-part version number as far as package systems (rpm, deb, etc.) are concerned: 1, 9, 0, beta, 6, 1.