Version Numbers

[Sebastian Huber]

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.
>>>
>>> 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. 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

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.