----- Chris Johns <chr...@rtems.org> schrieb: > On 28/07/2015 6:01 am, Sebastian Huber wrote: > > > > ----- Gedare Bloom <ged...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
