[rtems commit] cpukit: Add description of release version numbers

[Christian MAUDERER]

Hello Sebastian,

Am 28.01.22 um 14:16 schrieb Sebastian Huber:
> On 28/05/2021 08:25, Christian Mauderer wrote:
>> Module:    rtems
>> Branch:    master
>> Commit:    023a27096223e33be1cdd3f8d2ccf11caeda72b1
>> Changeset: 
>> http://git.rtems.org/rtems/commit/?id=023a27096223e33be1cdd3f8d2ccf11caeda72b1 
>>
>>
>> Author:    Christian Mauderer <christian.mauderer at embedded-brains.de>
>> Date:      Wed May 26 09:39:13 2021 +0200
>>
>> cpukit: Add description of release version numbers
>>
>> The release version in the git sources doesn't change. Add a note why
>> that is the case.
>>
>> ---
>>
>>   cpukit/include/rtems/version.h | 21 +++++++++++++++++++++
>>   1 file changed, 21 insertions(+)
>>
>> diff --git a/cpukit/include/rtems/version.h 
>> b/cpukit/include/rtems/version.h
>> index 87d5e14..cdd8905 100644
>> --- a/cpukit/include/rtems/version.h
>> +++ b/cpukit/include/rtems/version.h
>> @@ -32,6 +32,27 @@ extern "C" {
>>    * @brief The Version API provides functions to return the version 
>> or parts of
>>    * the version of RTEMS you are using.
>>    *
>> + * A branch in the version control system will always fall back to a
>> + * NOT-RELEASED version number with a minor number of 0. Only the 
>> release
>> + * archives have a VERSION file with a final release number. That 
>> means for
>> + * example that the 5 development branch will still show a version 
>> 5.0.0 even
>> + * after the 5.1 release.
>> + *
>> + * The reason for that are the following:
>> + *
>> + * 1. All pre-release tests are performed with a specific git hash. A 
>> committed
>> + * VERSION file would need to be changed and committed afterwards for 
>> releasing
>> + * with the required release version causing the released version to 
>> have a
>> + * different git hash and the test results couldn't be linked to the 
>> released
>> + * version.
>> + *
>> + * 2. Users deploying RTEMS would need to commit a local change to a 
>> committed
>> + * VERSION file and that would clash with the project changes. 
>> Deployment can
>> + * use the project repos directly.
>> + *
>> + * 3. The VERSION file management and generation is the 
>> responsibility of the
>> + * release manager and the release process.
>> + *
>>    * @{
>>    */
>>
>> _______________________________________________
>> vc mailing list
>> vc at rtems.org
>> http://lists.rtems.org/mailman/listinfo/vc
> 
> I think this contracts the description in the RTEMS Software Engineering 
> manual:
> 
> https://docs.rtems.org/branches/master/eng/release-process.html#release-version-numbering 
> 

I agree: The manual you linked has the following text:

"The release branch will have the version number N.M.1 with M being the 
last minor release of this series."

That's not the same as in my comment.

> 
> As far as I understood the process, RTEMS releases are made of a 
> specific Git commit and the only additional change is the setting of the 
> release version number.

I asked about the expected behavior in May 2021:

   https://lists.rtems.org/pipermail/devel/2021-May/067442.html

Chris explained the behavior to me and I wrote that comment so that I 
don't have to ask again:

   https://lists.rtems.org/pipermail/devel/2021-May/067451.html

So basically the current behavior on our 5 release branch is that the 
number is always 5.0.0 if we work from a git repository. A release 
number like 5.1.0 will be only used, if there is a VERSION file like in 
the release archives.

So I think at the moment, the engineering manual is wrong. The release 
branch will always have the number N.0.0 as long as we don't change the 
release process.

Best regards

Christian

> 
> Having a branch commit after lets say RTEMS 9.8.0 which still says it 
> has a version of 9.0.0 makes the RTEMS version information on branches 
> quite useless. According to the RTEMS Software Engineering manual we 
> would have:
> 
> Git commit X: version 9.0.0
> 
> Release manager checks out X, changes version to 9.1.0
> 
> Git commit X + 1: version 9.1.1
> 
> ...
> 
> Git commit X + Y: version 9.7.1
> 
> Release manager checks out X + Y, changes version to 9.8.0
> 
> Git commit X + Y + 1: version 9.8.1
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/