Documentation | eng: Update the release procedure (!62)

[Chris Johns (@chris)]

Chris Johns commented on a discussion on eng/release-process.rst: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/62#note_113558

 >  
 >     .. code-block:: none
 >  
 > -     rsync --rsh=ssh -arv 5.1.0 chrisj at dispatch.rtems.org:/data/ftp/pub/rtems/releases/5/.
 > +     rsync --rsh=ssh -arv 6.1 chrisj at dispatch.rtems.org:/data/ftp/pub/rtems/releases/6/.
 >  
 >  #. Test a build of the ``beagleboneblack`` BSP.
 > +
 > +VERSION File Format
 > +===================
 > +
 > +#. The ``VERSION`` is only generated when making releases. It shall not

Thanks, I have added some mode about this.

The version detail in the `VERISON` file is parsed and then embedded into the tool or package being built. In `rtems.git` it is a header file that is installed plus the version string is compiled into an object file. The `rtems all` command prints all known version details. The tests also print this detail with each test so a capture of the test output lets you know the release the test output is from.

In the RSB the `VERSION` data is added to the GCC version string and you can see that by invoking `gcc` with the `--version` option. For example:

```
aarch64-rtems6-gcc (GCC) 13.3.0 20240521 (RTEMS 6, RSB 8fc070bc4a6b4382e4fefbe5872aebb009f976e9, Newlib 1b3dcfd)
```

This procedure deals with releases where the git hash is replaced by the release string. A vendor making an RTEMS package for users is encouraged to embed something about themselves using the release label.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/merge_requests/62#note_113558
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/20241024/9294a006/attachment-0001.htm>