Version Numbers

Chris Johns chrisj at
Fri Sep 11 02:46:44 UTC 2015

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:
>> "Version Numbering Scheme for GCC 5 and Up"
>> In think we should simply use the same. This is more or less in line
>> with the proposal from Gedare:
> 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.



More information about the devel mailing list