Release workflow

[cedricchevalier19]

Observation

I have some thoughts about the releases of Arcane, all its subproducts and Alien. I put the message here to centralize the reactions but it does not necessarily mean that we have to adopt the same exact solution for all the products.

Currently, releases are frequent, unannounced and not concerted between projects. The main advantage to release on the flow is to provide users the latest features as soon as possible, in a kind of continuous delivery. These very small increments in code are very often associated with small version number increases, that do not necessarily relate to the degree of changes in the API.
It makes also hard for packagers (Spack, ...) to follow the different releases.

We can think of different release strategies. I'll try to present two but see this as a starting point for discussion.

ASAP strategy

We can keep the current strategy to have a flexible release system. We should automatize cross checking between products version and packaging.
One way to perform this release scheme is to tag on the fly the main branch with the new version number.

Positive aspects

• fastest delivery to user of new features
• easy to adapt to very busy development
• all latest features are released
• no deadline pressure

Potential problems

• relationship between components are hard to follow
• API changes are difficult to monitor except if we use a strict semver scheme
• cannot select features that goes in a version
• packaging can miss new versions
• bug fixes are hard to track

Fixed release schedule

We choose a fixed release schedule, meaning that we will a new versions monthly, quarterly, monthly.
Some time before the release date, a new branch is created. Selected features can be cherry-picked and then stabilized for the release.

Positive aspects

• documentation and bugs can be fixed during the integration period
• packaging can be anticipated
• we can number the version by the "date", making versioning coherent between the components
• expected features can be listed and tracked in advance
• only bug fixes are allowed after release, making them easy to track
• we can flag a version as longer term support
• deadline pressure, can help to put an end to a never ending iterative development

Potential problems

• time between releases can sometimes be too long
• over selecting features for the release can be a nightmare to maintain
• one more branch to keep
• deadline pressure

Discussion for @arcaneframework/arcane-team and @arcaneframework/alien-team .

[cedricchevalier19]

Anyway, we should add a "releasing protocol", at least with a checklist of actions, or even better we should make this checklist to run automatically.

[grospelliergilles]

Le principe de base est d'essayer de tendre vers de la distribution continue.
Cela est nécessaire pour les développeurs utilisateurs de Arcane en tous cas qui ont besoin de réactivité.

Les versions taggées dans le dépot framework correspondent à des versions qui ont passé tous les tests de non-régression des codes. Comme c'est long à faire et que ce n'est pas automatisé, cela n'est pas fait régulièrement: 1 fois tous les deux mois environ.

Si on veut des releases plus régulières pour spack, il est possible de faire un autre dépot qui package tout cela régulièrement et met à jour automatiquement les recettes.

[stdcm]

Thanks @cedricchevalier19 for starting this discussion, it is worth exchanging on this point.
Moving to french to explain our needs @ifpen : je séparerai la question des release et du versions

• pour nos applis nous n'aurons pas besoin d'un rythme de release plus soutenu que ce qu'il y a déjà ;
• Ok pour dire qu'il faut bien clarifier les conditions d'un changement de version, (majeure, mineure etc), en particulier par rapport au changement d'API. Même si on a toujours une excellente rétro-compatibilité avec Arcane :-) 🥇