High Level Coordination and Control

High Level Coordination and Control HLCC is an upper software layer in the ELT telescope's Central Control Software (CCS).
It uses the Local Supervisory software layer and provides services to the instruments.

Versioning

HLCC project adheres to the Semantic Versioning specification. Additionally, each version has release notes provided in the project's changelog. HLCC team maintains the changelog following keep a changelog guideline.

HLCC project provides public and internal releases:

• Public Release - public releases are meant to be used, for example, by ELT instrument consortia and later on in Armazones. They are tested and should provide a certain level of stability. The team releases patched versions with fixes for important bugs reported against the public release. Public versions consist of three parts MAJOR.MINOR.PATCH, and doesn't have pre-release and build metadata labels, e.g., 1.1.0. The project increments sections of the version according to the SemVer specification:
  • MAJOR - a version of the software which introduces backward-incompatible API changes
  • MINOR - a version of the software which adds functionality in a backward-compatible manner
  • PATCH - a version of the software which includes only backward-compatible bug fixes
• Internal Release - the project does internal releases at the end of each iteration. ESO uses internal releases for test and integration purposes. They are subject to QA verification. Internal releases may be recognized by having a pre-release label, e.g., 1.2.0-pre1. HLCC project uses the following pre-release labels:
  • pre - it is the stage of new public version development where developers implement and merge features and changes.
  • rc - it is a Release Candidate for a public version where the project focuses on identifying and fixing defects.

Example version cycle:

1.2.0-pre1 -> 1.2.0-pre2 -> 1.2.0-rc1 -> 1.2.0
      (int. release)  (int. release) (public release)

Release Procedure

General rules

• Git tags for versions should contain the prefix v, e.g., v1.2.0.
• Internal and Public releases should be tagged.
• Tags and release commits should be signed by the release engineer.
• Release branches should contain as prefix part of version: major or major.minor and .x as a suffix. E.g., 1.x or 1.2.x.
  • A release branch has structure major.x if it is a candidate for future minor and patch releases.
  • A release branch has structure major.minor.x if it is a candidate for future patch releases.
• Release branches, by default, are created for public releases.
• It is recommended to use bump2version for version management.

bump2version and git usage examples

• The end of an iteration should result in the release tag and incrementation of the version for the next development cycle. e.g., 1.2.0-pre2 -> 1.2.0-pre3

  $ git tag -a -m "End of iteration 42" v1.2.0-pre2
  $ bump2version build

• Changing stage from pre to rc, e.g., 1.2.0-pre3 -> 1.2.0-rc2

  $ bump2version release

• Public release, e.g., 1.2.0-rc1 -> 1.2.0

  $ bump2version --tag --message="Release v{new_version}" release

• Bumping version after public release,

  • E.g., 1.1.0 -> 1.1.1-pre1.

    $ bump2version patch

  • E.g., 1.1.0 -> 1.2.0-pre1.

    $ bump2version minor

  • E.g., 1.1.0 -> 2.0.0-pre1.

    $ bump2version major

• Manually set release number and tag (for cases not handled by predefined transitions):

  • E.g., 1.2.0-pre2 -> 1.2.0

    $ bump2version --tag --message="Release v{new_version}" --new-version 1.2.0 release

For more details on bump2version, see the Knolewage Base.

Release checklist

• [ ] Checkout locally the master of HLCC (or a proper branch if necessary)
• [ ] Ensure all required changes for a release are merged.
• [ ] Ensure the changelog is complete by checking Git log and Jira dashboard.
• [ ] If found, add missing entries to the changelog.
• [ ] Add a new version with a release date to the changelog.
• [ ] Create release commit and the tag. For example:
  • git add CHANGLOG.md
  • git commit -m "Release v1.1.2"
• [ ] Bump version for the next iteration with bump2version.
• [ ] Double-check the correctness of new commits and the release tag.
• [ ] Push changes directly to master / a proper branch in the HLCC repository, including the tag.
  For example:
  • git push
  • git push origin v1.1.2
• [ ] Bump versions of RPM packages in OBS.
• [ ] Publish new RPM packages in the desired repositories.
• [ ] Test installation of the new RPM packages.
• [ ] In the case of internal release, announce it on eltdevenv@eso.org.