Thank you for this.
On 26/5/21 7:41 pm, Christian Mauderer wrote:
> The release version in the git sources doesn't change. Add a note why
> that is the case.
> ---
> cpukit/include/rtems/version.h | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/cpukit/include/rtems/version.h b/cpukit/include/rtems/version.h
> index a8aff732f3..2e068cd976 100644
> --- a/cpukit/include/rtems/version.h
> +++ b/cpukit/include/rtems/version.h
> @@ -29,6 +29,18 @@ 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
I would use `NOT-RELEASED`.
> + * 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 is the following: All pre-release tests are performed
> for
> + * a specific git hash. If the VERSION file would be changed and committed
> + * afterwards for releasing a new version, the released version would have a
> + * different git hash and the test results couldn't be linked to the released
> + * version.
Close .... what about :
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.
Chris
_______________________________________________
devel mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/devel
