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

[Aleksey Nogin]

On 30.05.2007 16:55, Jason Hickey wrote:

>    1. Either we
>       a. Apply each jumbo patch in topological order to produce a
>          release canidate with a clean history, or
>       b. use svn cp to create it from an existing jumbo entry.
> 
>       I don't know which is better.  Note that I won't be keeping the
>       git around, so it _might_ be nicer to keep the features cleanly
>       separated in the svn history (initially).

I think that eventually we should merge all the patches one-by-one. 
However, I would prefer working on the "semi-stable" branch (AKA current 
0.9.8.x) for a little while before landing the patches. For a "preview" 
release of "unstable", it probably does not matter.

>    2. On the web, I believe the right thing to do is to put
>       up the web site/documentation for the unstable branch too.

Yes; we need to figure out how to manage the mapping from web URLs to 
branches better. Right now it's defined in the Apache configs, which 
means that I have to remember to update it whenever branches change. 
Also, we would often have the documentation generated off the latest SVN 
version, which does not match any of the released code...

>       I don't know if it should be called "roadmap", or "what's new".

Or both - call is "roadmap" on the "stable" and "semi-stable" branches 
and "what's new" on the "unstable" release...

>> 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".
> 
> I don't really care, just make a decision that is not one of the 0.??.* 
> schemes.
> 
> Note that 1.0.0.pre.* does not connote stability.  However, it does 
> connote change, which is very accurate.

Note that 1.0.0.pre.* will break:
  - Version monotonicity for RPM and OMake (1.0.0.x > 1.0.0 for any "x")
  - Windows versioning (version must be a tuple of _numbers_, of length 
<= 4, where only first 3 numbers are considered significant).

I understand your dislike of 0.90, but it's still the best I can come up 
with, given the following constraints (listed from most to least 
important for me):

- Version monotonicity (preferably for all the relevant comparison 
functions)
- "Space" for [potential] new version numbers for the "stable" 
"semi-stable" and "unstable" releases
- Version numbers that do not mislead too much w.r.t the _relative_ 
stability of releases.
- Version "jumps" that reasonably reflect the magnitude of changes, 
especially changes that are not fully compatible.

BTW, numbering the pre-releases .90-.99 is a fairly standard thing. Just 
from Google - 120,000 for "version 0.90" and 304,000 for "version 0.99".

> IMHO, the stability argument is a lost cause.  For stability, you want 
> 0.9.8.3, and it may remain that way for quite some time.  This kind of 
> situation is not all that unusual in the free software community.  If 
> you are waiting for a time of calm and stability, when the world is just 
> perfect like it is, and that time in nirvana can be called "1.0", then 
> we are already dead.

I do not expect nirvana. I just think that it's nice to have 1.0 fall at 
least under "one of the most stable releases so far, where we hope not 
to start breaking compatibility right away".

Aleksey