On 11/09/2015 1:54 am, Joel Sherrill wrote: > > > On 9/10/2015 2:56 AM, Sebastian Huber wrote: >> >> >> On 10/09/15 09:49, Pavel Pisa wrote: >>> Hello Sebastian, >>> >>> On Thursday 10 of September 2015 08:52:37 Sebastian Huber wrote: >>>> On 28/07/15 09:48, Chris Johns wrote: >>>>>>>>>>>>> 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. > > That's a nominal use of 4.12 as "next". :) > > But I would like to remove some ports and BSPs. > >>>>> 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. >>>> We have the 4.11 release branch, but still no release. > > The primary issues that I know of is ftp site clean up. Did we reach > any consensus on that? > >>>> Independent of >>>> that, we have to adjust the version of the master. Will this be 4.12.99 >>>> or 5.0.0? >>> If there is 4.12 planned then it should be 4.11.99. >> >> Hm, yes. >> >>> >>> As for 4.99 and 5.0, I am not big fan of today fashion >>> to have three or more major numbers per year as Firefox and Chrome >>> has. So if there is really significant API change then the major >>> version increase is appropriate but if there is not than to stay >>> with single one with minor up to 20 or 30 is reasonable. >>> On the other hand if minor should reach 50 or even 100 then >>> I am for major increase. May it be that rule to not go with >>> minor above 9 could be used. >>> >>> But above is only my feeling. But rule that complete version increase >>> is monotonic in master branch and in release does not reach any >>> version in master is critical. I have code which builds (thanks to >>> versions >>> macros) from 4.6 to 4.11. >> >> There was some discussion about version numbers in this thread. See also: >> >> https://devel.rtems.org/wiki/Developer/Release#RTEMSReleaseNumberingandNaming >> >> >> "Version Numbering Scheme for GCC 5 and Up" >> >> https://gcc.gnu.org/develop.html >> >> In think we should simply use the same. This is more or less in line >> with the proposal from Gedare: >> >> https://lists.rtems.org/pipermail/devel/2015-July/012056.html > > At the moment, I am in the don't care category. I just want waf > and buildbot.
I am in the "I do care" category. > > My intention of a quick "4.12" was to get rid of some ports > and BSPs, so there would be less to convert to waf and test > with buildbot. I agree. > That ignores new stuff that is beyond the scope of putting > on a release branch. Which we already have with the lower > overhead API to support OpenMP and other infrastructure > libraries. I think we should make use of the major number more. I think it is currently redundant and we should make use of it. I documented in the wiki [1] what I understand as a way forward based on discussions with Amar. Chris [1] https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
