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