[PATCH rtems v2] cpukit: Add description of release version numbers

[Chris Johns]

Ok and thanks. :)

On 27/5/21 6:56 pm, Christian Mauderer wrote:
> The release version in the git sources doesn't change. Add a note why
> that is the case.
> ---
> v2: Integrate suggestions from Chris Johns.
> 
>  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 87d5e1492c..cdd8905735 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.
> + *
>   * @{
>   */
>  
>