On 15/10/17 02:13, Joel Sherrill wrote:
On Oct 12, 2017 11:37 PM, "Sebastian Huber" <sebastian.hu...@embedded-brains.de <mailto:sebastian.hu...@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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
