----- Am 11. Nov 2017 um 5:06 schrieb Chris Johns chr...@rtems.org: > On 10/11/2017 17:30, Sebastian Huber wrote: >> On 09/11/17 23:52, Joel Sherrill wrote: >>> My question about the version number went unanswered. Is this the point >>> were we are switching to two digit versions? This thread has 5.0.0 in the >>> title (3 digits, no change in style) but the current tools are "*-rtems5" >>> which >>> implies two digit release numbering. Can I get a clarification on that? >> >> Yes, the new number scheme. >> >> Master 5.0.0 >> First release 5.1.0 (spelled as 5.1 in documents, etc.; exactly one commit >> has >> this version) >> Branch after first release 5.1.1 >> Second release in this series 5.2.0 (spelled as 5.2) >> Branch after second release 5.2.1 > > How do the milestones now work in Trac? I see we have 5.0, 5.1 etc. Will there > be milestones for 5.1.0, 5.1.1, etc?
No, we have 5.1, 5.2 and 6.1 milestones. > >> Next master 6.0.0 >> >> Tools use just "5". >> > > I have been wondering about this for a while because I was concerned about > rtems5 and no rtems5.1, rtems5.2, etc as we have had for the 4 series. I think > rtems5 will work if we add configure checks for newlib into the kernel, libbsd > etc. > > GCC's interfaces are stable and do not move that much, it is newlib that > changes > requiring us to build new tools. If a check for gcc and newlib was added to > the > top level configure script of RTEMS we would be able protect users from > attempting to build RTEMS with the wrong version of tools. If this is > something > that should happen I can create a ticket. We already have such a check in RTEMS. If you build the master with the 4.12 tools, you get a configure error which tells you to update the tools via RSB. I hope that the Newlib/GCC interface stabilizes now. You don't have the C++11 support, POSIX header file move, self-contained POSIX synchronization objects, OpenMP support, etc. every year. One missing piece is the ucontext support for Go. > > This change means users need to use prefixes when supporting more than one > release. I would need to review the User manual and see what it says. I think nothing changes here, you need a RTEMS 4.10, 4.11, 4.12 prefix, now its a 5 prefix. We should define a default prefix pattern and adjust the documentation accordingly, e.g. $HOME/rtems/$version, or /opt/rtems/$version. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
