RTEMS_VERSION on 5 branch

[Chris Johns]

On 25/5/21 8:56 pm, Christian MAUDERER wrote:
> Hello,

Great question :)

> if I build a BSP on the 5 branch, I still have the following defines in cpuopts.h:
> 
> #define RTEMS_VERSION "5.0.0"
> #define __RTEMS_MAJOR__ 5
> #define __RTEMS_MINOR__ 0
> #define __RTEMS_REVISION__ 0
> 
> We are past 5.1. Is it an expected behavior that the 5 branch head still tells
> that it is a 5.0.0? 

It is expected.

> Did I do something unexpected when compiling and everyone
> else gets a 5.1? 

You have not done anything wrong.

> Any pointers what would have to be fixed?

These settings indicate the build is from the release branch. If we updated
these values to reflect the next release we would then have a number of
differing tarballs in the wild with the same values, for example release
candidates that have different contents.

Consider the branch settings as "NOT-RELEASED". If you are deploying from a
release branch for internal or customer focused reasons add a VERSION file to
the top of the released sources. I know rtems-tools and the RSB support this but
I am not sure rtems.git waf does. I think it should and have it as part of the
release activities for RTEMS 6. A single VERSION file is easy to audit.

Note, there is a subtle corner case here. If you perform all your testing for a
release on a specific git hash and then perform a further commit to set the
"VERSION" for the release the git hash you tested and the hash you release are
not the same and there is ability to link one to the other. You also need a
further commit to move the branch past the release commit or you potentially
have the same information in more than one release testing tarball. The "release
commit" can be branched and this is problematic to manage. As a result the
branch defaults to "NOT-RELEASED" automatically on all commits it has and we add
a VERSION file to manage the version. The tarball checksum manages the integrity
of the files.

Chris