[RTEMS Project] #2886: RTEMS version is wrong on 4.11 branch

[RTEMS trac]

#2886: RTEMS version is wrong on 4.11 branch
-----------------------------+------------------------------
 Reporter:  sebastian.huber  |       Owner:  sebastian.huber
     Type:  defect           |      Status:  new
 Priority:  normal           |   Milestone:  4.11.2
Component:  General          |     Version:  4.11
 Severity:  normal           |  Resolution:
 Keywords:                   |
-----------------------------+------------------------------

Comment (by chrisj):

 Replying to [comment:2 sebastian.huber]:
 > Release procedures should be updated to do a version change to 4.11.2.0
 as the last commit before the 4.11.2 release.

 I am not sure how we should handle this. I see a couple of possible
 solutions, your suggestion is one. The other is to only ever tag a release
 when generating the source tarball and a not released type version number
 always held in the repo.

 The objective is to make no changes between final testing and the release
 however this is not that simple to do because we have conflicting
 requirements. From a V&V point of view it is simpler if the testing and
 any generated documentation for a release is made against the repo hash
 (commit) that is used for the release.

 The conflicting requirements can be simplified as:

 1. Create the test reports against the repo hash.
 2. Do not create a release until all testing has been done to meet the
 release milestones.
 3. Only ever create a single tarball instance for a release.

 An aborted or failed release needs to move to the next dot point release
 and the failed or aborted release number abandoned. It is better to
 document a failure and to provide a traceable corrective measure. It is
 important there is no possible way a duplicate release of code could exist
 that could be different and we should avoid equivalents.

 Changing the repo by adding a special commit to create a release means any
 testing against a specific repo hash (commit) is different to the release
 hash because an extra commit has been added. This means there needs to be
 extra steps in the auditing process to verify any or all releases. The VC
 is distributed and can be edited adding complexity. While the likely hood
 of this ever happening is low, we need to be able to show it has not
 happened and for each release.

 A method I have used successfully in the past is to use something like
 `4.11.NOT_RELEASED` in the repo. Any code built from the repo is clearly
 identified as ''not released'' by default. When the release tarball of
 code is created the version labels in the code are changed to the dot
 point release number for the release. This does mean the code in the repo
 at the hash is not the same as the code in the release however it does
 mean there is only one definitive release tarball that can be created and
 the process of doing this is controlled by the release procedure and it
 does not require interactions with an external shared repo.

 The release script is open and available for auditing so a V&V team can
 verify the changes made to the code checked out from the repo at the
 release hash. I have seen V&V perform a build of the code from the repo at
 the release hash before release tagging and also from the released source
 code then performing a binary diff on the binary images of the complete
 system. The auditing procedure contained a list of agreed exceptions, the
 release tags, date/time stamps if present, and checksums.

 Note, I am not a fan of the `99` version numbering for development we
 currently use.

--
Ticket URL: <http://devel.rtems.org/ticket/2886#comment:3>
RTEMS Project <http://www.rtems.org/>
RTEMS Project