Release Process

Directives

• decisionengine and decisionengine_modules can have feature releases or bugfixes release
• decisionengine and decisionengine_modules will have concurrent quarterly feature releases. Feature releases:
  • Have a change in major and/or minor version number
  • Include new features
  • Start a release series (releases sharing the same major.minor version number)
  • Start a branch in the repository for the release series
• Only bug fixes are ported to the release series branches
• Bugfix releases will result in increased patch version number
• Bugfix releases of decisionengine and decisionengine_modules are independent
• At each time two release series are supported N and N-1
• Release version tags are 3 numbers separated by dots (major.minor.patch). Feature releases end always with ".0"
• Release series branch names are the first 2 numbers of the included release versions, dot separated (major.minor)

Making a new release

The release branch is master for a new feature release, a release series branch for bugfix releases

1. Add or edit the release notes in doc/source/release_notes/. There is one file per release series. Release notes should include: name, date, a summary with what is new and important notes for operators or users, list of GitHub issues resolved, list of commits

2. Before a release, the code should pass all the CI tests (code in the main repository should always do)

3. Tag the software in the current branch with the release version for a release candidate, e.g. 1.5.1.rc1

4. Build the distribution (RPMs) and the documentation (GitHub pages)

   • RPMs a built nightly in the FNAL Jenkins server: https://buildmaster.fnal.gov/buildmaster/view/CI/job/decisionengine_pipeline/
   • Build the RPMs manually:

     git clone https://github.com/HEPCloud/decisionengine.git
     ./decisionengine/setup.py bdist_rpm

     and

     git clone https://github.com/HEPCloud/decisionengine_modules.git
     # For unit tests ./decisionengine_modules/.github/actions/unittest-in-sl7-docker/entrypoint.sh
     ./decisionengine_modules/.github/actions/rpmbuild-in-sl7-docker/entrypoint.sh

     To build a bugfix release you can checkout the branch or clone directly only the release series branch with something like git clone --depth 1 --branch 1.5.0 ... Pre 1.6.0 releases of decisionengine are built with the github action as well: ./decisionengine/.github/actions/unittest-in-sl7-docker/entrypoint.sh

5. Test the release/candidate

   • Communicate that the release/candidate is ready for testing
   • The package should be installed in a clean host and should start correctly
   • Tests may take a few days

6. Get the release notes reviewed/approved

   • Send an email to the board to review/approve the release notes

7. Apply changes and iterate (from the beginning) if needed

8. Once the release notes are approved and the release passes the basic test cut the release: tag the software with the release version, e.g. 1.5.1, and cut the release as above

9. Publish the RPMs in the yum repo on ssirepogpvm01

10. Advertise the new release

    • Send an email to the stakeholders' list to announce the release

11. After a release has been cut, the release candidates tags can be removed

Additional steps for a new feature release (start of a new release series)

After cutting and testing the release candidates as described above in the master branch, during step 8, tag the new release series in master, e.g. 1.5.0, and branch the release series branch off that, e.g. 1.5. The release build can happen in either master or the release branch, which should be identical at this point.