Re: 1.12 dev version number

[Kaz Kylheku]

Derek Robert Price <derek@ximbiot.com> wrote in message 
news:<mailman.1454.1044456351.21513.bug-cvs@gnu.org>...
> I currently have the trunk marked as 1.12.0.1, which is potentially 
> confusing since previously thius would have meant the dev version 
> _after_ a 1.12 release.
> 
> Any opinions on whether I should:
> 
>    1. Call it 1.11.99.1 on the premise that we will never reach a stable
>       1.11.99 release anyhow.
>    2. Call it 1.12.0.0 and temporarily defy our previous standard,
>       possibly resulting in some error reporters thinking it okay to
>       truncate version numbers and report errors in 1.12.
>    3. Change the standard and call the post 1.12 version 1.12.1.1 on the
>       premise that it is leading up to 1.12.1.
>    4. Do something else entirely.

Among the 4 options would be: do the Linux kernel thing. Odd numbers
are experimental, even are release. So in this model, you would have a
stable 1.10 code stream, with builds like 1.10.{1,2,3, ...} then you
would branch it and on the trunk have experimental 1.11.{1,2,3, ...}.
When the trunk reaches stability, you put that out as 1.12, branch it
and switch to the odd 1.13 for the trunk.

The whole dilemma stems from not having a naming scheme which reflects
the reality that you have experimental and stable streams happening
much of the time.

The 1.11.9x method simply is a way of borrowing unused numbers from
the stable stream to name releases in development stream.

The 1.12.0.x method is a way of adding another digit to create
something distinct from 1.12.x; this is logically equivalent to using
even versus odd numbers.

Instead of the zero, you could use some symbol, like ``exp'' for
experimental. So the picture is:

  1-12-exp-N --- experimental versions after 1.11 release. N starts at
1.
 
  1-12       --- 1.12 release, culmination of 1-12-exp-N patches. No
integer
                 suffix at all.

  1-12-N     --- careful patches to correct 1.12 issues found after
release,
                 N starts at 1.

  1-13-exp-N --- wild feature development from 1-12, merging 1-12-N.

People just have to understand that 1-12-exp-3 is unrelated in any way
to 1-12-3. It's not clear whether the zero does it better or a symbol
like ``exp'', ``prerelease'', ``pre'' or whatever.

My problem with zero is that because it is numeric, it looks like the
version 1.12.0.1 comes *after* 1.12---that it's a patch to 1.12. But
in fact that's not the case; it's the first experimental build leading
toward the eventual release of 1.12.

This is how most users will understand version numbers; one with a
suffix is lexicographically posterior to one without the suffix, the
same way that the word ``at'' comes after ``a'' in a dictionary.

> I prefer #3 at the moment but I am still interested in hearing arguments 
> for alternatives.

#3 is bad because, again, an apparently greater version number,
1.12.1.1 is leading up to an apparently smaller one: 1.12.1.

The first version after 1.12 will be experimental, so call it
1.12.exp.1. The infix ``pre'' is used in many projects, so maybe
that's better.

It's still not immediately clear that 1.12.pre.1 comes before 1.12,
based on the naive rule that if a suffix is added to something, it
indicates a later version. But at least the observation that there is
a non-numeric component at least alerts mind of the intelligent reader
that there might be some non-obvious semantics in the naming.