[PATCH] Upgrade to 5.0.0

[Sebastian Huber]

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 chrisj at 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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.