#2886 closed defect (wontfix)

RTEMS version is wrong on 4.11 branch

Reported by: Sebastian Huber Owned by: Sebastian Huber
Priority: normal Milestone: 4.11.2
Component: unspecified Version: 4.11
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

cat find -name version.m4
AC_DEFUN([RTEMS_VERSIONING],
m4_define([_RTEMS_VERSION],[4.10.99.0]))

m4_define([_RTEMS_API],[4.11])
AC_DEFUN([RTEMS_VERSIONING],
m4_define([_RTEMS_VERSION],[4.10.99.0]))

m4_define([_RTEMS_API],[4.11])
AC_DEFUN([RTEMS_VERSIONING],
m4_define([_RTEMS_VERSION],[4.10.99.0]))

m4_define([_RTEMS_API],[4.11])
AC_DEFUN([RTEMS_VERSIONING],
m4_define([_RTEMS_VERSION],[4.10.99.0]))

m4_define([_RTEMS_API],[4.11])

Change History (4)

comment:1 Changed on Jan 26, 2017 at 7:32:31 AM by Sebastian Huber <sebastian.huber@…>

In 69ae534cbb97e0961532cdc7fc5233098d62d886/rtems:

Change version to 4.11.1.99

Update #2886.

comment:2 Changed on Jan 26, 2017 at 7:33:10 AM by 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.

comment:3 in reply to:  2 Changed on Feb 5, 2017 at 11:49:33 PM by Chris Johns

Replying to 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.

comment:4 Changed on Mar 21, 2017 at 3:56:46 AM by Chris Johns

Resolution: wontfix
Status: newclosed

I am going to close ticket this and have the 4.11 branch sit at 4.10.99. Anything built from git on the branch will be given "the branches" version number.

It does mean the git source at the tag and "the release" tarball vary and the release script needs to update the version numbers in the source tree, which it already does, as part of cutting a release. Changing the process to make commits when tagging make the release procedure more complicated when dealing with release candidates or we end up with a whole bunch of release candidate commits to something and back again in-order to "correctly" tag a release.

The other way of looking at this issue is to say the tag in the repo is the commit the release was based on and the release tarball is "the release" and nothing else is or can be that release. A suitable hash of the release tarball defines exactly "the release". This approach means the release scripts and repo are not touched during the release process, including release candidates, and this should make an audit of the what a release is simpler. The release scripts clearly define what is touched and that can be audited.

Note: See TracTickets for help on using tickets.