Version numbers of unreleased stable and development versions

Version numbers of unreleased stable and development versions

[Reiner Steib]

Hi,

we have skipped the release of 5.10.7 because there were already too
many "5.10.7" versions around in the wild.

In order to avoid this confusion after bumping the version in CVS as
we did before (after releasing N.n, bump to N.n+1), I think we should
add only a string like "+cvs" [1].  The User-Agent should then say
something like:

| Gnus/5.1008 (Gnus v5.10.8+cvs) Emacs/21.3 (gnu/linux)

| Gnus/5.110004 (No Gnus v0.4+cvs) Emacs/22.0.50 (gnu/linux)

The variable `gnus-version-number' and the output of
`gnus-continuum-version' should probably not increased.

We could add something like `gnus-cvs-version' which is t or nil and
add the "+cvs" appropriately.

Instead of "+cvs" we might even think about adding the date e.g.
"+20060411".  For this we'd need either CVS keywords or bump it
manually from time to time.  Hm, `gnus-cvs-version' could also be a
number like 20060411.

Bye, Reiner.

[1]
,----[ <f1> v mh-version RET ]
| mh-version is a variable defined in `mh-e.el'.
| Its value is "7.93+cvs"
| 
| Documentation:
| Version number of MH-E.
`----
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Version numbers of unreleased stable and development versions

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> writes:

> Instead of "+cvs" we might even think about adding the date e.g.
> "+20060411".  For this we'd need either CVS keywords or bump it
> manually from time to time.

In the MH-E project, just adding +cvs seems to work fine since we bump
the version number relatively frequently.

However, it would be easy enough to implement a before-save-hook which
adds the date instead of cvs if any of the project's files are saved
that the developers could all add to their .emacs.

I've cc'd the MH-E users and invite them to comment whether they would
find this feature useful.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Version numbers of unreleased stable and development versions

[Lars Magne Ingebrigtsen]

Bill Wohler <wohler@newt.com> writes:

> However, it would be easy enough to implement a before-save-hook which
> adds the date instead of cvs if any of the project's files are saved
> that the developers could all add to their .emacs.

If everybody keeps checking in changes to that one line of code all
the time, then there'll probably be lots of conflicts to resolve...

Anyway, how about using an odd/even-numbered methodology?  The
odd-numbered ones are in CVS, and when a release is published, it gets
the next even number.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbers of unreleased stable and development versions

[Bill Wohler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Bill Wohler <wohler@newt.com> writes:
>
>> However, it would be easy enough to implement a before-save-hook which
>> adds the date instead of cvs if any of the project's files are saved
>> that the developers could all add to their .emacs.
>
> If everybody keeps checking in changes to that one line of code all
> the time, then there'll probably be lots of conflicts to resolve...

Yeah, you're probably right. You can always say no or not check in
mh-e.el (in our case) if your check-in is small. However, it would
probably be best if only one developer were to update it. Thanks for
pointing that out.

> Anyway, how about using an odd/even-numbered methodology?  The
> odd-numbered ones are in CVS, and when a release is published, it gets
> the next even number.  

I find the +cvs or +date to be more explicit. A user might not be
aware we're playing the odd/even game and would be very confused to
see an odd number in the X-Mailer and not see the release in our
collection of tarballs.

p.s. Hope you're feeling better!

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: Version numbers of unreleased stable and development versions

[Lars Magne Ingebrigtsen]

Bill Wohler <wohler@newt.com> writes:

> I find the +cvs or +date to be more explicit. A user might not be
> aware we're playing the odd/even game and would be very confused to
> see an odd number in the X-Mailer and not see the release in our
> collection of tarballs.

That's true.  I guess my only objection to the "+cvs" is that I don't
think it looks all pretty and stuff.  :-)

> p.s. Hope you're feeling better!

I am; thanks.  Only a few more days of coughing to go before normality
is achieved. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Version numbers of unreleased stable and development versions

[Romain Francoise]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Anyway, how about using an odd/even-numbered methodology?

I'd prefer that to the '+cvs' solution.

Or we could come up with two more code names for the CVS versions of the
stable and development releases and keep the same version numbers.  One
can never have enough code names.

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Version numbers of unreleased stable and development versions

[Reiner Steib]

On Wed, Jun 13 2007, Reiner Steib wrote:

> Personally, I'm not convinced that this would be clearer than an
> odd/even thingie.  I'm waiting for Lars to make a decision so that we
> can apply the new scheme and make a new 5.10.x release now that Emacs
> 22.1 has been released.

I asked Lars about it.  He prefers to use (for the least significant
number in the version numbers): even numbers for releases and odd
numbers for CVS versions.

Lars also agreed that we should make new releases soon (i.e. Gnus
5.10.10 and No Gnus 0.8).  I will comment on this in a separate
thread.

Maybe going straight to 0.10 for No Gnus would be better as both least
significant numbers are the same then for trunk and v5-10.

So we'll have the following scheme from now on:

,-----------------------------------------------------------------------.
| Standalone | CVS     || No Gnus | CVS   | Date / notes                 |
| Gnus vers. | v5-10   ||         | trunk |                              |
| beta rel.  |         || devel   |       |                              |
|------------|---------||---------|-------|------------------------------|
|            | 5.10.8  ||         |       |                              |
|            |         || 0.6     |       | 2007-05-01                   |
|            | 5.10.8  ||         | 0.7   | today                        |
| 5.10.10    |         || 0.10    |       | soon after Emacs 22.1 = ASAP |
|            | 5.10.11 ||         | 0.11  |                              |
| 5.10.12    |         || 0.12    |       | with Emacs 22.2 or sooner    |
|            | 5.10.13 ||         | 0.13  |                              |
| 5.10.14    |         || 0.14    |       |                              |
|            | 5.10.15 ||         | 0.15  |                              |
`------------------------------------------------------------------------'

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Version numbers of unreleased stable and development versions

[Reiner Steib]

On Mon, Jun 04 2007, Didier Verna wrote:

> OK, here's what I finally understand:
>
> - there's the development branch (the trunk) in CVS with the unstable version

Correct.

> - there's the stable branch in CVS

Correct.

> - there's ALSO a stable branch in GNU Emacs'CVS

Correct.  But apart from version numbers and missing XEmacs-specific
files, the two are identical.

> and then,
>
> - the unstable branch leads or should lead to official beta versions
>   from time to time

Correct.  But Lars doesn't label these "beta".  "beta" is the label
for the standalone stable releases (5.10.x, ...).

> - BOTH stable branches should lead to official patchlevel versions from
>   time to time
> - which in turn lead to official stable patchlevel releases.

Correct.

> So here's what I think would be the most human-readable version
> numbering scheme:
>
> In the trunk
> ============
> Gnus 6.0 beta 1 cvs 2007-08-01
>                     2007-08-02
>                     ..........
>                                Gnus 6.0 beta 1 => Tagged beta release
>
> Gnus 6.0 beta 2 cvs 2007-09-01
>                     2007-09-02
>                     ..........
>                                Gnus 6.0 beta 2 => Tagged beta release
>
> [ etc, finally leading to Gnus 6.0 ]

(Maybe your 6.0 numbers were simply examples, but for the record: No
Gnus will probably become 5.12/5.13)

What would be the value of `gnus-continuum-version' (used for
`gnus-convert-old-newsrc')?

> In the stable branch
> ====================
> (while the trunk gets Gnus 6.1 beta)
>
>                                Gnus 6.0        => Tagged stable release
>
> Gnus 6.0.1 cvs 2007-10-01
>            cvs 2007-10-02
>                ..........
>                                Gnus 6.0.1      => Tagged stable release
>
> Gnus 6.0.2 cvs 2007-11-01
>            cvs 2007-11-02
>                ..........
>                                Gnus 6.0.2      => Tagged stable release
>
> [ etc ]

From a user perspective, it may be confusing to get the difference
between Gnus 6.0.1 and Gnus 6.0 beta 1.

> In the GNU Emacs repository
> ===========================
>
> Gnus 6.0.1 emacs cvs 2007-10-01
>            emacs cvs 2007-10-02
>                      ..........
>                                Gnus 6.0.1
>
> Gnus 6.0.2 emacs cvs 2007-11-01
>            emacs cvs 2007-11-02
>                      ..........
>                                Gnus 6.0.2
>
> [ etc ]

A couple of years I suggested to add a third number to the Gnus
version in Emacs (22.1: 5.11.1, 22.2: 5.11.2, ...).  But Larsi and
others didn't think it's useful:
<http://thread.gmane.org/gmane.emacs.gnus.general/58421>.

> And of course, the stable patchlevel tags should be synchronized between
> our repository and that of GNU Emacs.
>
> So, to summarize:
>
> Unstable versions are: Gnus <major>.<minor> beta <level>
> Stable   versions are: Gnus <major>.<minor>.<patchlevel>
>
> For intermediate CVS versions, add: [emacs] cvs yyyy-mm-dd
>
> This is verbose, but quite clear I think. One could also wish to be more
> coherent between stable and beta numbering, in which case we could also
> think of: Gnus <major>.<minor> patchlevel <number>
>
> Wadya think ?

Personally, I'm not convinced that this would be clearer than an
odd/even thingie.  I'm waiting for Lars to make a decision so that we
can apply the new scheme and make a new 5.10.x release now that Emacs
22.1 has been released.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Version numbers of unreleased stable and development versions

[Didier Verna]

OK, here's what I finally understand:

- there's the development branch (the trunk) in CVS with the unstable version
- there's the stable branch in CVS
- there's ALSO a stable branch in GNU Emacs'CVS

and then, 

- the unstable branch leads or should lead to official beta versions
  from time to time
- BOTH stable branches should lead to official patchlevel versions from
  time to time
- which in turn lead to official stable patchlevel releases.

So here's what I think would be the most human-readable version
numbering scheme:


In the trunk
============
Gnus 6.0 beta 1 cvs 2007-08-01
                    2007-08-02
                    ..........
                               Gnus 6.0 beta 1 => Tagged beta release

Gnus 6.0 beta 2 cvs 2007-09-01
                    2007-09-02
                    ..........
                               Gnus 6.0 beta 2 => Tagged beta release

[ etc, finally leading to Gnus 6.0 ]


In the stable branch
====================
(while the trunk gets Gnus 6.1 beta)

                               Gnus 6.0        => Tagged stable release

Gnus 6.0.1 cvs 2007-10-01
           cvs 2007-10-02
               ..........
                               Gnus 6.0.1      => Tagged stable release

Gnus 6.0.2 cvs 2007-11-01
           cvs 2007-11-02
               ..........
                               Gnus 6.0.2      => Tagged stable release

[ etc ]


In the GNU Emacs repository
===========================

Gnus 6.0.1 emacs cvs 2007-10-01
           emacs cvs 2007-10-02
                     ..........
                               Gnus 6.0.1

Gnus 6.0.2 emacs cvs 2007-11-01
           emacs cvs 2007-11-02
                     ..........
                               Gnus 6.0.2

[ etc ]


And of course, the stable patchlevel tags should be synchronized between
our repository and that of GNU Emacs.


So, to summarize:

Unstable versions are: Gnus <major>.<minor> beta <level>
Stable   versions are: Gnus <major>.<minor>.<patchlevel>

For intermediate CVS versions, add: [emacs] cvs yyyy-mm-dd


This is verbose, but quite clear I think. One could also wish to be more
coherent between stable and beta numbering, in which case we could also
think of: Gnus <major>.<minor> patchlevel <number>


Wadya think ?


-- 
Read the Jazz Blog !! http://jazzblog.didierverna.com

Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

Re: Version numbers of unreleased stable and development versions

[Reiner Steib]

On Tue, May 29 2007, Didier Verna wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>> One of the major points for this discussion was to distinguish CVS
>> versions and released version.  Now, if a user has "5.10.8" you can't
>> tell if its from 2006-04-11 or 2007-05-28, i.e. it's unclear which
>> bugs should already be fixed in this version.
>
>         We should have CVS tags in all files. 

?

> But if you really want to give explicit versions to CVS
> intermediate, then you can use a timestamp.

I don't argue strongly for this, but it would be okay with me:

,----[ http://article.gmane.org/gmane.emacs.gnus.general/62634 ]
| Instead of "+cvs" we might even think about adding the date e.g.
| "+20060411".  For this we'd need either CVS keywords or bump it
| manually from time to time.  Hm, `gnus-cvs-version' could also be a
| number like 20060411.
`----

>> Upto now we had/have:
>> - final = in Emacs = { 5.9, 5.11, 5.13, ... } 
>> - beta = standalone release = { 5.8.x, 5.10.x, ... }
>> - development = (prefixed named versions = ) = { Oort Gnus 0.y, No
>>   Gnus 0.y, ...)
>>
>> How do you suggest to apply your scheme to these Gnus versions (i.e. 
>> fill the table from my message with your suggested version numbers)?
>
>         Thanks for this table. I'm actually beginning to understand the
> Gnus version numbering scheme now that we're about to change it ;-) 

;-)

> I can't quite answer your question because I still don't understand
> the relation between No Gnus and Gnus 5.10.*.

,----[ (info "(gnus-coding)Gnus Maintainance Guide"), texi/gnus-coding.texi ]
| 2.1 Stable and development versions
| ===================================
| 
| The development of Gnus normally is done on the CVS trunk, i.e. there
| are no separate branches to develop and test new features.  Most of the
| time, the trunk is developed quite actively with more or less daily
| changes.  Only after a new major release, e.g. 5.10.1, there's usually a
| feature period of several months.  After the release of Gnus 5.10.6 the
| development of new features started again on the trunk while the 5.10
| series is continued on the stable branch (v5-10) from which more stable
| releases will be done when needed (5.10.7, ...).  *Note Gnus
| Development: (gnus)Gnus Development.
| 
|    Stable releases of Gnus finally become part of Emacs.  E.g. Gnus 5.8
| became a part of Emacs 21 (relabeled to Gnus 5.9).  The 5.10 series will
| become part of Emacs 22 (as Gnus 5.11).
`----

Is this sufficient?

> Perhaps I would, if the table was presented as a graph of CVS
> branches.

There are two relevant branches: trunk (= development version = No
Gnus) and stable (= v5-10 = 5.10.n n > 6).

> Besides, your table lacks any stable realease of Gnus (I know, Gnus
> is never stable ;-).

I wrote:

,----
| In Emacs (final versions of Gnus):
|   Emacs 21: Gnus 5.9
|   Emacs 22: Gnus 5.11
|   Emacs 23: Gnus 5.13
`----

In the table, you may add it as a left-most column which only contains
"5.11".

> But if this table means that we actually have *two* development branches
> in parallel (the 5.10 and the trunk), then that's not the numbering
> scheme which is broken; it's the development process !

The v5-10 branch is active (we add bug fixes, doc-fixes, ...), but
there is no additions of new features (sometimes one can argue about
whether a change is still a bugfix or already a new feature).

> (again, I'm not quite sure but I fear this has something to do with
> GNU Emacs people committing changes to Gnus in the GNU Emacs
> repository instead of the Gnus CVS archive)

Does `texi/gnus-coding.texi' explain it?  If not, please explain.

,----[ (info "(gnus-coding)Gnus Maintainance Guide") ]
| 2.2 Syncing
`----

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Version numbers of unreleased stable and development versions

[Didier Verna]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Mon, May 28 2007, Didier Verna wrote:
>
>> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>>
>>> Releases (beta and devel) from Gnus repository and CVS versions:
>>>
>>> ,-----------------------------------------------------------------------.
>>> | Standalone | CVS     || No Gnus | CVS   | Date / notes                 |
>>> | Gnus vers. | v5-10   ||         | trunk |                              |
>>> | beta rel.  |         || devel   |       |                              |
>>> |------------|---------||---------|-------|------------------------------|
>>> |            | 5.10.8  ||         |       |                              |
>>> |            |         || 0.6     |       | 2007-05-01                   |
>>> |            | 5.10.8  ||         | 0.7   | today                        |
>>> | 5.10.9     |         || 0.9     |       | close to release of Emacs 22 |
>>> |            | 5.10.10 ||         | 0.10  |                              |
>>> | 5.10.11    |         || 0.11    |       | ?                            |
>>> |            | 5.10.12 ||         | 0.12  |                              |
>>> | 5.10.13    |         || 0.13    |       |                              |
>>> |            | 5.10.13 ||         | 0.14  |                              |
>>> `------------------------------------------------------------------------'
>>
>>         My .02: I've never understood why people like this kind of
>> numbering scheme. I find them so confusing and inconsistent (John uses
>> odd/even, Jack uses even/odd, you never know which one is what etc).
>
> One of the major points for this discussion was to distinguish CVS
> versions and released version.  Now, if a user has "5.10.8" you can't
> tell if its from 2006-04-11 or 2007-05-28, i.e. it's unclear which
> bugs should already be fixed in this version.

        We should have CVS tags in all files. But if you really want to
give explicit versions to CVS intermediate, then you can use a timestamp.


> Upto now we had/have:
>
> - final = in Emacs = { 5.9, 5.11, 5.13, ... } 
>
> - beta = standalone release = { 5.8.x, 5.10.x, ... }
>
> - development = (prefixed named versions = ) = { Oort Gnus 0.y, No
>   Gnus 0.y, ...)
>
> How do you suggest to apply your scheme to these Gnus versions (i.e. 
> fill the table from my message with your suggested version numbers)?

        Thanks for this table. I'm actually beginning to understand the
Gnus version numbering scheme now that we're about to change it ;-) I
can't quite answer your question because I still don't understand the
relation between No Gnus and Gnus 5.10.*. Perhaps I would, if the table
was presented as a graph of CVS branches. Besides, your table lacks any
stable realease of Gnus (I know, Gnus is never stable ;-).

But if this table means that we actually have *two* development branches
in parallel (the 5.10 and the trunk), then that's not the numbering
scheme which is broken; it's the development process ! (again, I'm not
quite sure but I fear this has something to do with GNU Emacs people
committing changes to Gnus in the GNU Emacs repository instead of the
Gnus CVS archive)


So here's a partial answer, assuming the next release of Gnus would be
6.0: the *only* place where development in beta stage occurs (or should
occur) could be numbered as:

Gnus 6.0 beta 1 cvs 2007-08-01
                    2007-08-02
                    ..........

Gnus 6.0 beta 1                 => Tagged beta release

Gnus 6.0 beta 2 cvs 2007-09-01
                    2007-09-02
                    ..........
Gnus 6.0 beta 2                 => Tagged beta release

[ etc ]

Gnus 6.0                        => Tagged stable release


And then, the trunk goes to Gnus 6.1 beta 1 cvs blabla, while the 6.0
branch occasionally gets bugfixes and goes Gnus 6.0.1 etc.



Now I'm waiting to see the light about this mysterious 5.10 ghost...


-- 
Read the Jazz Blog !! http://jazzblog.didierverna.com

Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

Re: Version numbers of unreleased stable and development versions

[Reiner Steib]

On Mon, May 28 2007, Didier Verna wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>
>> Releases (beta and devel) from Gnus repository and CVS versions:
>>
>> ,-----------------------------------------------------------------------.
>> | Standalone | CVS     || No Gnus | CVS   | Date / notes                 |
>> | Gnus vers. | v5-10   ||         | trunk |                              |
>> | beta rel.  |         || devel   |       |                              |
>> |------------|---------||---------|-------|------------------------------|
>> |            | 5.10.8  ||         |       |                              |
>> |            |         || 0.6     |       | 2007-05-01                   |
>> |            | 5.10.8  ||         | 0.7   | today                        |
>> | 5.10.9     |         || 0.9     |       | close to release of Emacs 22 |
>> |            | 5.10.10 ||         | 0.10  |                              |
>> | 5.10.11    |         || 0.11    |       | ?                            |
>> |            | 5.10.12 ||         | 0.12  |                              |
>> | 5.10.13    |         || 0.13    |       |                              |
>> |            | 5.10.13 ||         | 0.14  |                              |
>> `------------------------------------------------------------------------'
>
>         My .02: I've never understood why people like this kind of
> numbering scheme. I find them so confusing and inconsistent (John uses
> odd/even, Jack uses even/odd, you never know which one is what etc).

One of the major points for this discussion was to distinguish CVS
versions and released version.  Now, if a user has "5.10.8" you can't
tell if its from 2006-04-11 or 2007-05-28, i.e. it's unclear which
bugs should already be fixed in this version.  The releases (stable
5.10.x or development No Gnus 0.y) should have a different version
than the CVS snapshots.  And the version comparisons (via
gnus-continuum-version) must still work correctly.

In http://thread.gmane.org/gmane.emacs.gnus.general/62634 I suggested
to use ...

| Gnus/5.1008 (Gnus v5.10.8+cvs) Emacs/21.3 (gnu/linux)
| Gnus/5.110004 (No Gnus v0.4+cvs) Emacs/22.0.50 (gnu/linux)

... or "+20060411" for CVS versions.  But Lars suggested an odd/even
scheme.  I don't have a strong preference for either one, but I'd like
to have a decision soon.

> - <major>.<minor> beta <level> for development branches
> - <major>.<minor>.<patchlevel> for stable branches

Upto now we had/have:

- final = in Emacs = { 5.9, 5.11, 5.13, ... } 

- beta = standalone release = { 5.8.x, 5.10.x, ... }

- development = (prefixed named versions = ) = { Oort Gnus 0.y, No
  Gnus 0.y, ...)

How do you suggest to apply your scheme to these Gnus versions
(i.e. fill the table from my message with your suggested version
numbers)?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: Version numbers of unreleased stable and development versions

[Zlatko Calusic]

Didier Verna <didier@xemacs.org> writes:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>
>> Releases (beta and devel) from Gnus repository and CVS versions:
>>
>> ,-----------------------------------------------------------------------.
>> | Standalone | CVS     || No Gnus | CVS   | Date / notes                 |
>> | Gnus vers. | v5-10   ||         | trunk |                              |
>> | beta rel.  |         || devel   |       |                              |
>> |------------|---------||---------|-------|------------------------------|
>> |            | 5.10.8  ||         |       |                              |
>> |            |         || 0.6     |       | 2007-05-01                   |
>> |            | 5.10.8  ||         | 0.7   | today                        |
>> | 5.10.9     |         || 0.9     |       | close to release of Emacs 22 |
>> |            | 5.10.10 ||         | 0.10  |                              |
>> | 5.10.11    |         || 0.11    |       | ?                            |
>> |            | 5.10.12 ||         | 0.12  |                              |
>> | 5.10.13    |         || 0.13    |       |                              |
>> |            | 5.10.13 ||         | 0.14  |                              |
>> `------------------------------------------------------------------------'
>
>         My .02: I've never understood why people like this kind of
> numbering scheme. I find them so confusing and inconsistent (John uses
> odd/even, Jack uses even/odd, you never know which one is what etc).
>
>
> In my personal projects, I use the following scheme:
>
> - <major>.<minor> beta <level> for development branches
> - <major>.<minor>.<patchlevel> for stable branches
>
>
> Isn't that much more natural and human readable ?

I agree with you, completely.

I never know what version I'm running, is it the newest one, is it
development or stable. Tried few times in the past, but concluded that
it's too hard to grok that. :)

So, these days I just let Debian maintainer to choose the version for
me. :)
-- 
Zlatko

Re: Version numbers of unreleased stable and development versions

[Didier Verna]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> Releases (beta and devel) from Gnus repository and CVS versions:
>
> ,-----------------------------------------------------------------------.
> | Standalone | CVS     || No Gnus | CVS   | Date / notes                 |
> | Gnus vers. | v5-10   ||         | trunk |                              |
> | beta rel.  |         || devel   |       |                              |
> |------------|---------||---------|-------|------------------------------|
> |            | 5.10.8  ||         |       |                              |
> |            |         || 0.6     |       | 2007-05-01                   |
> |            | 5.10.8  ||         | 0.7   | today                        |
> | 5.10.9     |         || 0.9     |       | close to release of Emacs 22 |
> |            | 5.10.10 ||         | 0.10  |                              |
> | 5.10.11    |         || 0.11    |       | ?                            |
> |            | 5.10.12 ||         | 0.12  |                              |
> | 5.10.13    |         || 0.13    |       |                              |
> |            | 5.10.13 ||         | 0.14  |                              |
> `------------------------------------------------------------------------'

        My .02: I've never understood why people like this kind of
numbering scheme. I find them so confusing and inconsistent (John uses
odd/even, Jack uses even/odd, you never know which one is what etc).


In my personal projects, I use the following scheme:

- <major>.<minor> beta <level> for development branches
- <major>.<minor>.<patchlevel> for stable branches


Isn't that much more natural and human readable ?

-- 
Read the Jazz Blog !! http://jazzblog.didierverna.com

Didier Verna, didier@lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier@xemacs.org

Re: Version numbers of unreleased stable and development versions

[Reiner Steib]

On Fri, Mar 23 2007, Reiner Steib wrote:

> On Thu, Mar 22 2007, Katsumi Yamaoka wrote:
[ Wrong version numbers in the manuals ]
>> So is the Message info.  I vote to making them synch to
>> `gnus-version', as well as the ones in the Emacs CVS and
>> the v5-10 branch.  It will make releasing new versions easy.
>
> Well, the Makefile rules (see "release-bump-version") I've added
> before releasing 5.10.8 already do the job automatically.  But Lars
> didn't seem to have used them for the release of No Gnus v0.5.

... and No Gnus 0.6.  ;-)

> Another point is, that we started some discussion about a new version
> number policy, but IIRC we didn't come to a final conclusion and/or
> nobody stepped forward to put into practice.
>
> ,----[ <news:m37j5vxvjv.fsf@quimbies.gnus.org> ]
> | Anyway, how about using an odd/even-numbered methodology?  The
> | odd-numbered ones are in CVS, and when a release is published, it gets
> | the next even number.  
> `----
>
> <http://thread.gmane.org/gmane.emacs.gnus.general/62634>
> <http://thread.gmane.org/gmane.emacs.gnus.general/62660>
> <http://search.gmane.org/?query=Version%20numbers%20of%20unreleased%20stable%20and%20development%20versions&group=gmane.emacs.gnus.general>

,----[ Lars in http://article.gmane.org/gmane.emacs.gnus.general/62660 ]
| Anyway, how about using an odd/even-numbered methodology?  The
| odd-numbered ones are in CVS, and when a release is published, it gets
| the next even number.  
`----

As the versions in Emacs (which are supposed to be the stable release
versions) have odd numbers (5.9, 5.11), it might be better to do it
the other way round: even = CVS (unrelease), odd = release.

Thus, we will have the following scheme...

In Emacs (final versions of Gnus):
  Emacs 21: Gnus 5.9
  Emacs 22: Gnus 5.11
  Emacs 23: Gnus 5.13
  ...

Releases (beta and devel) from Gnus repository and CVS versions:

,-----------------------------------------------------------------------.
| Standalone | CVS     || No Gnus | CVS   | Date / notes                 |
| Gnus vers. | v5-10   ||         | trunk |                              |
| beta rel.  |         || devel   |       |                              |
|------------|---------||---------|-------|------------------------------|
|            | 5.10.8  ||         |       |                              |
|            |         || 0.6     |       | 2007-05-01                   |
|            | 5.10.8  ||         | 0.7   | today                        |
| 5.10.9     |         || 0.9     |       | close to release of Emacs 22 |
|            | 5.10.10 ||         | 0.10  |                              |
| 5.10.11    |         || 0.11    |       | ?                            |
|            | 5.10.12 ||         | 0.12  |                              |
| 5.10.13    |         || 0.13    |       |                              |
|            | 5.10.13 ||         | 0.14  |                              |
`------------------------------------------------------------------------'

But I don't care too much whether we use odd/even or even/odd
(CVS/release) actually, but it would be nice to make a decision soon.
I'd volunteer to adjust the release-* rule in Makefile.in accordingly.

As the release of Emacs 22.1 seems to get really closer finally
(<http://thread.gmane.org/E1HrUMp-0007iw-FX%40fencepost.gnu.org>), it
would be nice to release a new 5.10.* soon after this.  I'd volunteer
to prepare the tar-balls etc.

Additionally, (as sketched in the table) I'd propose release trunk and
v5-10 at the same time (as we did for 5.10.8 and No 0.4) to have the
same bug fix level.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/