Version Numbers

[Pavel Pisa]

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.

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.

Best wishes,

             Pavel