Version Numbers

[Gedare Bloom]

Extrapolating a bit, we would have:
4.11.0 release series (following old conventions)
5.0 next development version, no release
5.1 next release, with 5.2, 5.3, 5.4 as subsequent bugfix (maintenance) releases
6.0 next development version after 5.0
6.1 next release after 5.1, with 6.2, 6.3, 6.4 as before?

The alternate scheme I have seen suggested is more convoluted, and it
involves using even numbers for development versions, and odd numbers
for releases. In this scheme we would have:
5.0 next development version, no release
5.1 next release, with 5.2 as the development version of the bugfix
branch, and 5.3 as the bugfix release.
6.0 is development version after 5.0.
6.1 next release, with 6.3, 6.5, etc as bug fix.

The advantage of this scheme is that all development versions have a
clear label. The question boils down to do we care to provide
development version numbers of maintenance branches?

Either scheme fits pretty well with RTEMS release cycle I think. Even
if we can get down to one release per year, the numbers won't grow
terribly fast.

Gedare

On Mon, Jul 27, 2015 at 3:40 PM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> Hello,
>
> shortly before I go on holiday, I thought it is a good time to start a discussion about version numbers. GCC recently changed their version number scheme and it might be something that fits also quite good for RTEMS.  The major releases are indicated by the left-most number followed by a dot and then we have 0 for the development version, 1 for the first major release, 2 for the first bugfix release, and so on.  So for example the next major release of RTEMS would be 5.1 and the master branch currently 5.0.
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel