RTEMS milestones 4.13 and 5.0?

[Sebastian Huber]

On 15/10/17 02:13, Joel Sherrill wrote:
>
>
> On Oct 12, 2017 11:37 PM, "Sebastian Huber" 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     On 12/10/17 16:24, Chris Johns wrote:
>
>         On 11/10/17 11:30 pm, Sebastian Huber wrote:
>
>             milestones 4.13 and 5.0 don't fit the new version scheme:
>
>             https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering
>             <https://devel.rtems.org/wiki/Developer/Release#RTEMSRelease5SeriesAndHigherNumbering>
>
>
>             I suggest to rename the 5.0 milestone to 5.1 and move all
>             4.13 tickets to 5.1.
>
>         A change to the major revision number requires a major change.
>
>
>     In the new version scheme the major number changes with every
>     release.
>
>
>         The reality is
>         4.12 should be 5.0. The release and what it contains has grown
>         considerable and
>         we are currently attempting to converge on stability across
>         all hosts and
>         architectures before we branch. Looking at 4.12 now it appears
>         to me to be a
>         good 5.0 candidate so should this happen or is it too late?
>
>         We have planned the move to 5.0 to be a build system change.
>         The work to make
>         this important and needed change is not small and I cannot do
>         it without funding
>         and I do not have any for this work. Moving to 5.0 after 4.12
>         without something
>         major may result in a long wait while planned 5.0 changes are
>         implemented. As a
>         result we will have smaller things hanging on the development
>         branch that should
>         be released as we have with 4.12 now. We added 4.13 as a way
>         to keep us keep
>         moving with releases while we figure out now to make the build
>         system change. I
>         do not like having 4.13 but I do not see another path. Jumping
>         to 5.0 is a solution.
>
>
>     Using 5.1 for the next release is probably less confusing for
>     users since a lot of stuff changed (current master would be 5.0.0,
>     release is 5.1.0, branch version after release is 5.1.1). Someone
>     would have to do this number change.
>
>
>
> Historically we bumped the first digit on major architectural or 
> feature changes. IMO 4.11 should have been 5.0 due to addition of SMP. 
> Now that it is very optimized and we feel it is ready for production 
> use, I think bumping to 5.x is the right thing to do.

We have also the 64-bit time_t, the network stack header consolidation 
and the move to Newlib, the self-contained POSIX synchronization objects 
(impacting the configuration) and a improved Ada support (however, not 
all Ada tests pass currently).

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