GENESIS: Documentation

Related Documentation:

Release Procedure

A release is a bundle with a consistent set of software packages required to use the GENESIS simulator. Internal releases are built on a daily basis, public release are built on a monthly to yearly basis.

A public release has the guarantee that it passes all the regression tests. Internal releases are tested to, but can show minor problems.

The following pre-release procedure would be desirable:

• When we feel a release is ready, create a release branch.
• Only bug fixes should be committed to the release branch; any other work goes to the main branch.
• Some developers volunteer to be a designated tester for particular platforms. Ideally, we would have two testers per platform (because build setups differ), but one would be sufficient.

  A working buildbot can be a designated tester. Note that it needs to be configured to work on the release branch.

• Testing must also include creating and testing the release package for each platform.

  I think the current buildbots don’t do this step.

• After all designated testers have reported success, the release is declared finally ready, and published as usual.
• Propagate the release branch to the main branch, for the bug fixes.

Every release is identified with a tag. The tag (see below for a definition) allows to reconstruct the release source code from the repositories using the developer package. This helps in solving problems reported by users.

• Define the tag
  • In principal, developer tags follow the naming convention:

    <milestone-number>

    So, for example, for the current release, the tag is des-10, which is the tenth subrelease after starting development of the des milestone.

  • Milestone labels point to an important event for development.
  • Tag numbers are monotonically increased per milestone.
  • Some packages may skip some releases, milestone labels, and/or tag numbers.
  • Internally, the development system refers to the milestone labels as ‘majors’, the numbers as ‘minor’s’, and for future use, there is also a ‘micro’ number possible.
• Set the tag using neurospaces_build: Use the options --tag, e.g. neurospaces_build --tag des-10. Use additional options to select individual packages if needed.
• Build the tarballs:
  • Use the UNIX shell command neurospaces_dist.
  • Use additional options such as --regex and --enable to select individual packages if required.
  • Use the --certification-report to annotate the monotone revision with the output of the build (this step is optional).
• Build the OS specific packages:
  • Use the UNIX shell command neurospaces_release.
  • Use additional options such as --regex and --enable to select individual packages if required.
  • Use the --certification-report to annotate the monotone revision with the output of the build (this step is optional).
• Put the files on an file server.
• For examples, see the DeveloperPackage

  It might be useful to do “make html-upload” for some packages after the release, to synchronize the content of the website with the content of the downloadable packages.