About the Nordugrid ARC Releases

This page collects general information concerning the releases of the Nordugrid ARC software.

An ARC release is defined as the ARC source package AND the corresponding binary packages on the supported platforms.

Release categories

The source package is identified by its major, minor and patch version number. The major and minor releases are scheduled releases, the path releases are unplanned fast-track releases to fix specific unexpected problems with the previous minor release.

An example of a scheduled release is NorduGrid ARC 7.1.0 where 7 refers to the major release series, and 1 to the minor. Whenever there is a specific patch release, addressing only one isolated issue with the previous minor release, the last digit is used, for instance 7.1.1.

The properties of a major are:

  • may break backward compatibility

  • introduces new components, features

  • obsoletes components

  • has longer term planning

  • 3-6 months preparation

  • can include alpha, beta, rcx test releases

  • bumps the major number in the version number

  • the contents mainly follow a high level ARC development roadmap

The properties of a minor release are:

  • includes bugfixes

  • can include new features and/or enhancements

  • can include new components

  • does not include anything that is backward incompatible

  • the release bumps the minor number in the version number

The Nordugrid ARC releases can come in three types: scheduled, express and binary update of a release.

Scheduled releases:

  • Minor releases are scheduled regularly monthly or bi-montly

  • Major releases are scheduled irregularly as needed, with frequency ranging from 1 to three years.

  • All developments that at the time of the release are already merged into master are included in the scheduled release

    • this means that backward incompatible changes are kept in separate development branches, and only merged before a major release is imminent.

Express releases:

  • is an unplanned urgent release to fix a security issue or a critical bug

  • maximum two weeks preparation

  • only development needed to fix the issue is included into the release in order to not delay the release or introduce new bugs

  • a separate branch is created from the point on master of the last release, and the release tag is created on this branch

  • bumps the third digit in the ARC release number by one: 7.1.0 -> 7.1.1.

Binary update of a release:

  • is sometimes needed due to a change in the external dependencies and ARC releases have to be rebuilt

  • this “semi release” does not affect the ARC source code, no re-tagging takes place, only new binaries are built

  • can happen for both major, minor or emergency releases

Testing

Testing needs to be done on several Linux distributions as ARC depends on a lot of software that has different versions on different distributions with different file structure.

The level of importance of the different Linux distributions is evaluated as follows:

  1. Rocky/AlmaLinux/CentOS Stream version 9.x architecture x86_64 is The Most Important version.

  2. Latest Ubuntu LTS, Latest Ubuntu, any architecture

  3. Fedora and other Ubuntu

  4. The rest.

Some OSes are more used server-side (RHEL-flavour) and some client-side (Fedora).

The testing of Nordugrid ARC is performed in levels, where level 1 and 2 are always performed, and level 3 is performed on the best-effort or as-needed -basis.

Level 1

All supported platforms are built on a nightly basis and publically available. Follow these instructions.

In addition ARC is built and deployed for the most important platforms on the GitLab CI platform. The deployment includes a basic functional test. Both supported platforms and tests are subject to ongoing development. Currently the build and deploy is performed on each commit to master.

Level 2

The release candidate is deployed on voulenteer sites (minimally 1) and on testing infrastructure available at the time. In particular the functionality affected by the development in the current release should be tested.

The test-site tracks his contribution to the test on in the GitLab Wiki.

Level 3

If necessary and possible, larger testing campaigns are organized using the release candidate in question (involving users and sysadmins outside the testing team). This campaign will follow a plan organized centrally by the Nordugrid ARC team. The sites report back on any issues seem, and may be asked to perform tests, and give a simple report back on the test results.

The tests and their reults are recorded on a dedicated pages in the Testing area of the ARC documentation

Release notes

Release notes are published here in our docs and http://www.nordugrid.org/arc/releases/ and are distributed in the following channels:

The following Web pages are updated upon a release:

ARC Git branching strategy

As of ARC 7 we do no longer have any master branch. The arc7 branch is the new default branch. The arc6 branch is the previous master branch containing the ARC 6 source code.

Our branching strategy:

../_images/arc_branching.svg