You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

What is an ACS Pre-Release/Release?

An ACS pre-release is a build of the integration branch of a given release with a number of 'New Feature', 'Improvement', 'Bug', etc. tickets merged into it (Last pre-release should include all the release changes). The ACS pre-release only has the developers good-to-go checks and may not include any interaction with other subsystems.

An ACS release is a build of the integration branch of a given release including all the changes planned for the release. The ACS release has the IRM team verification phase finished and all the passing tickets should be part of this release. If any of the tickets was considered a failure, then this should be removed from the release plan and not be part of the ACS release.

At the end, the ACS pre-release/release build is an artifact copied over from Jenkins to the webdav server, which can either be done manually, or using the job prepared in the release view in Jenkins.

Frequency

  • ACS Pre-releases and ACS Releases are expected to be published for each ALMA COMMON release
    • The minimum number of them is one ACS pre-release at the end of the implementation phase and one ACS release at the end of the verification phase
    • Optionally, intermediate ACS pre-releases could be made at intermediate points to help developers start working with bigger changes (RTI DDS, Java 11, Python 3, etc.)
    • Additional ACS pre-releases/releases may be required if important bugs are found in one of the published versions
  • No labels