Version Numbers

[Joel Sherrill]

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.

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.

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.


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985