RTEMS_VERSION on 5 branch

[Christian MAUDERER]

Hello Chris,

thanks for the detailed response. Should we add a bit of that to the 
doxygen documentation of the rtems_version_* functions so that I don't 
ask it again because I have forgotten it in a year?

Best regards

Christian

Am 26.05.21 um 01:24 schrieb 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
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/