[Omake] Releases and versioning (0.9.8.2, 0.9.8.3, 0.9.9, 0.90.0, ...?)

[Aleksey Nogin]

On 29.05.2007 18:32, Jason Hickey wrote:

>> I am thinking that it would probably be better to simply do 0.9.8.3 
>> (off the current "0.9.8.2" branch) rather than to try going for 
>> 0.9.8.2-3 (especially given that the initial attempt to release 
>> 0.9.8.2-1 was over a month ago!).
> 
> Why?  I admit that numbering doesn't have to be consecutive, but 0.9.8.2 
> has never been released, so there is no harm in using it.

Not quite - 0.9.8.2 was only never formally announced. However, 
0.9.8.2-1 was available for downloads for a while (until you went to 
build the OS X binaries and discovered that the first incarnation of the 
case-insensitive code was wrong); 0.9.8.2-2 is also currently online 
(although not linked to) and was partially added to GODI. Both were 
available on the up2date/yum channel (0.9.8.2-2 still is)... Lots of 
_different_ subversion revisions were marked with version.txt set to 
0.9.8.2-1 or 0.9.8.2-2.

I just want to make it easier to attribute any future bug report to the 
correct OMake version. I also want to be able to tell people with 
0.9.8.2 bugs right away "0.9.8.2 was buggy and was never formally 
released, you have an unofficial pre-released version, please upgrade to 
0.9.8.3 and try again".

>> I would also propose:
>>  - Renaming 0.9.8.2 back to 0.9.8.x and keeping it around for any 
>> follow-up bugfixes that might come up until we can release something 
>> off the other branch.
>>
>>  - Renaming the 0.9.8.x to 0.9.9.x (while the language changes are not 
>> that significant, they are significantly more than a simple feature 
>> enhancement/bugfix and it seems appropriate to do a larger version step)
> 
> Well, I don't really agree.  It feels to me that the motive behind these 
> numerical suggestions is simply to prevent progress.  

It's the opposite - I want to switch to the "new" branch ASAP, but the 
constant flow of bug reports for the "old" one keeps holding me back. 
Leaving a door open for "purely bugfix" releases off the "old" branch 
would make me a lot more comfortable with finally releasing the 
0.9.8.2/3 and moving on. Otherwise, I feel (probably wrongly) that I 
have to make sure that the "last old branch release" is sufficiently 
solid, before moving on into "unchartered territory", where it might be 
a while before we are ready for a new release.

Also, as I feel that I am the main "customer relations" person for OMake 
(answering most of the list traffic, etc), I feel obligated to make sure 
that any sufficiently incompatible changes are sufficiently reflected in 
version numbers to better "warn" users (who are very likely to expect 
that an upgrade from 0.9.8.2 to 0.9.8.3 would not break things - no 
matter how many times we tell them "it's alpha-quality, expect bugs").

> Think of how far we have come even since 0.9.6.

Right, and we failed to reflect this in our version numbering. The 
"TeX-style" version numbering is all well and good since they work 
really hard to preserve backwards compatibility. In OMake, we keep 
changing things (as we should), and we need to reflect that in version 
numbers. The fact that we failed to do that before should not be 
stopping us from doing it now.

> The code restructuring currently on the table is 
> insignificant in comparison.

Yes. But we are looking into some non-trivial user-visible changes 
(.STATIC, declare, etc, etc) - I definitely like the idea of making 
those sooner rather than later, but I would feel more comfortable doing 
that with a larger "jump" in version numbering.

Aleksey
-- 
Aleksey Nogin, Research Scientist
Advanced Technologies Department, Information & System Sciences Lab
HRL Laboratories, LLC, Malibu, CA