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 > [email protected]:/data/ftp/pub/rtems/releases/5/. > + rsync --rsh=ssh -arv 6.1 > [email protected]:/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.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
