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

[Aleksey Nogin]

On 30.05.2007 12:50, Jason Hickey wrote:

> On May 30, 2007, at 11:29 AM, Aleksey Nogin wrote:
> 
>>
>> My main issue with this approach is that calling a release "1.0" 
>> implies an obligation to make sure it's "extra stable". I think that 
>> it might be a waste of time to work on such "extra stability" until 
>> after the "naming" code is fully incorporated. I would prefer to 
>> stabilize the "code refactoring" and "keyword" stuff only as much as 
>> needed to created a solid base for the "naming" merge and concentrate 
>> the real stabilization efforts on post-"naming" code. This is the 
>> reasoning behind aiming to have the "post-naming" become the 1.0...
> 
> It is fine with me not to have a separate "keyword" release.

I would still like to heave a release off what is currently known as 
0.9.8.x, it's just I do not like the idea of calling it "1.0" (which 
would incorrectly imply some sort of "extra stable" designation). 
Personally, it think it ought to be called 0.9.9.

> Here is what I want,
>    - The naming (all the "jumbo" stuff) is numbered and released
>      simultaneously with 0.9.8.2/3.

It might be slightly easier to release them sequentially (packaging 
everything, building binaries, etc is a somewhat lengthy process and it 
would be nice not to have to do both simultaneously), "jumbo" right 
after 0.9.8.3.

Basically:
  0) Lm_db bug is investigated, hopefully fixed
  1) Branch names are agreed upon and "svn mv"s happen (possibly in 
parallel with 0).
  2) Aleksey does all the routine steps for 0.9.8.3
  3) Jason and Nathan build OS X binaries
  4) Aleksey announces 0.9.8.3 (mailing lists, freshmeat), with a note 
that an "unstable" release is forthcoming
  5) In parallel with 2-4, Jason is writing a "roadmap" document.
  6) With Jason's help Aleksey does the routine steps for the "unstable" 
"jumbo" release
  7) Binaries for the "jumbo" release are created
  8) "Jumbo" release is announced (mailing lists, freshmeat).

To make sure this all finally happens within a reasonable amount of 
time, I can commit to:
  - Not holding off 0.9.8.3 unless a new "really bad" bug is found; any 
sort of non-show-stopper bug will be dealt with in 0.9.8.4, if necessary

  - Not holding off the "unstable" release unless if fails to self-build 
on one of the platforms we care about.

>      This includes everything up through dll-{gtk,fuse,odbc}.
> 
>      I don't really care what the numbering is, but I suggest
>      1.0.0.pre.x or 1.0.0.rc.x.  0.90.x is aesthetically unacceptable.

The problem I am trying to solve is reflecting the magnitude of each 
change in version numbers, while maintaining the version monotonicity 
for various version comparison functions (rpm, OMake, Windows installer, 
etc). Calling a pre-1.0 version 1.0.something will surely break 
monotonicity. I'd suggest 0.99.0.x, but that's too easy to confuse with 
0.9.9... We can do 0.10.x, but 0.90.x is better at implying "these are 
the final days before 1.0".

P.S. While I feel kind of silly having this length discussion with such 
a superficial subject, but the version numbers do shape users' 
expectation and it would be nice not to be completely off here.

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