On 11/11/17 22:58, Chris Johns wrote:
On 11/11/17 7:40 pm, Sebastian Huber wrote:
----- 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.
How do you plan a release? Do all release branch tickets, ie 5.1, need to be
resolved to make the release, ie 5.1.3? Previously we could assign tickets to
5.1.3 and 5.1.4.
There will be no 5.1.X release with X != 0. We have a version scheme
change and not simply a major version number bump. I think is quite good
explained in the GCC development page how it works (Version Numbering
Scheme for GCC 5 and Up):
https://gcc.gnu.org/develop.html
We need something similar in the new engineering guide.
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.
I must be confused. Before this change we had tools named after the major and
minor version numbers in a release series, for example 4.9, 4.10, and 4.11 which
allowed a common prefix. The tools for 4.11 are $PREFIX/bin/*-rtems4.11-* and
libraries are under $PREFIX/*-rtems4.11. More formally written as:
${PREFIX}/bin/*-rtems${major}.${minor}-*
${PREFIX}/*-rtems${major}.${minor}
With this change we have moved to:
${PREFIX}/bin/*-rtems$[major}-*
${PREFIX}/*-rtems${major}
This is a significant change if you have not used separate prefixes before now.
What do you mean with separate prefixes? I doubt that you can build a
RTEMS 4.1 with the tool chain of RTEMS 4.10 and vice versa.
I assume we are not saying any rtems5 tool set will work with any series 5
release?
Any rtems5 tool must work with any series 5 release. The 5.2, 5.3, ...
are bug fix releases of 5.1.
This is the reason I raised the need to check the supported version of
newlib. It becomes difficult to catch mismatch errors when the tools are all
named after the major version number.
We should define a default prefix pattern and adjust the documentation
accordingly, e.g. $HOME/rtems/$version, or /opt/rtems/$version.
We need to document and educate about this change.
A RTEMS installation supporting several version could look like:
/opt/rtems/4.8
/opt/rtems/4.9
/opt/rtems/4.10/bin/X-rtems4.10-gcc
/opt/rtems/4.11
/opt/rtems/5/bin/X-rtems5-gcc
/opt/rtems/6 (maybe with the new build system)
/opt/rtems/7/bin/X-rtems7-gcc
--
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
