Version Numbers

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Jul 28 05:18:11 UTC 2015


----- Chris Johns <chrisj at rtems.org> schrieb:
> On 28/07/2015 6:01 am, Sebastian Huber wrote:
> > 
> > ----- Gedare Bloom <gedare at gwu.edu> schrieb:
> >> 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?
> > 
> > I am fine with this scheme.  So, there is basically a single Y.ODD commit for the release, and then a Y.ODD+1 commit to change the number for the next development cycle.  I think its nice if we can go from three numbers X.Y.Z to just two.  It should be clear for the user which version corresponds to a release, and what is work in progress. 
> > 
> 
> https://devel.rtems.org/wiki/Developer/Release#RTEMSReleaseNumberingandNaming
> 
> Amar ?

Nice, we already have a wiki page for this.  Maybe we should update the "RTEMS Release 5 Series And Higher Numbering" section with Gedare's scheme.

> 
> >>
> >> 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.
> > 
> > One release per year would be nice.
> > 
> 
> We may need more flexibility.

I just wanted to say, that the four years or so it took to release RTEMS 4.11 was a bit long.

-- 
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.



More information about the devel mailing list