RTEMS | waf: Fix handling of the VERSION file in a release (!257)
Chris Johns (@chris)
gitlab at rtems.org
Tue Oct 22 01:34:15 UTC 2024
Chris Johns commented on a discussion on wscript: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/257#note_113437
> + from waflib.Errors import WafError
> + release_label = "not-released"
> + try:
> + modified = ctx.cmd_and_log("git ls-files --modified",
> + quiet=Context.BOTH).strip()
> + release_label = ctx.cmd_and_log("git rev-parse --short HEAD",
> + quiet=Context.BOTH).strip()
> + if len(modified) != 0:
> + release_label += "-modified"
> + except WafError:
> + pass
> + return release_label
> +
> +
> +#
> +# This class is not aligned the project's release labelling. It will
Functionally there is none. The git hash or VC key is a **_kind of_** release label and there are other types of release labels. The release process uses the release label to identify an RC release. I had documented this as an **_identifier_** and in this change I am sharpening the definition by moving to the term **_release label_**.
My original view over 4 years ago was this label can used by service providers or users who have extra changes to label a release to aid their deployment and our public support processes.
Only the RTEMS project can make a release with an empty release label.
--
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/257#note_113437
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20241022/903507c1/attachment-0001.htm>
More information about the bugs
mailing list