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.
>>
>>> 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.
I assume we are not saying any rtems5 tool set will work with any series 5
release? 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.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
