On 28/07/2015 3:18 pm, Sebastian Huber wrote: > > ----- 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. >
Amar sent me some emails about this long ago to me and I need to dig them out. I have not had time today. I think the major number incrementing is a good idea. Tracking an API is not meaningful these days. We may have major releases that are not fit for production and we need to announce them as such. For example 5.0 and 6.0 will be for waf and header moves. >> >>>> >>>> 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. > Yes I agree. I think Joel wants a 4.12 which is close to 4.11 but stripped of various things we kept in 4.11. Once we have 5.0 and waf, buildbot will decide when a release is ready. When the feature set for the release is available and buildbot shows the code is suitable it can be released. It might be months or just weeks. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
