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

[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

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.

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 Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
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/