Version Numbers

[Chris Johns]

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