Gestion et maintenance des versions

De OpenESubWiki.

Sommaire

Les différentes versions d'openESub

Généralités

A partir de la version 1.0.0, le projet openESub a opté pour un système à trois versions (qui s'inspire largement de la gestion du système d'exploitation Debian/Linux) :

- une version de production (appelée "stable") qui est installée sur http://www.openesub.org ;

- une version de tests (appelée "testing") qui est installée sur http://testing.openesub.org et qui sert à la validation des modifications de la version "stable" ;

- une version de développement qui contient toutes les nouveautés (et tous les bugs aussi).

Les numéros de version

Les versions d'openESub sont numérotées sous la forme x.y.z :

- x est le numéro de version majeur, il n'évolue que lors de grosses réécritures et se traduit par une remise à zéro complète de la base de données ;

- y est le numéro de version mineur, il correspond à l'évolution des fonctionnalités (il est toujours pair pour une série "stable", impair sinon) ;

- z est le numéro de bugfixes (plus il grand, moins il y a de bugs...).

La version "stable"

La version stable, celle qui est installée en production sur http://www.openesub.org n'évolue pas en terme de fonctionnalités. On n'y apporte donc que des corrections de bugs. En terme de numérotation, les chiffres x et y ne bougent donc pas (dans le cas général).

La version "testing"

Cette version n'est pas une version "testing" au sens Debian (pour ceux qui connaissent) mais plûtot une version "pré-stable". On l'utilise pour valider les modifications qu'on va appliquer à la version de production. Elle pointe vers la même base de données que la version "stable" et on peut donc l'utiliser en routine pour jouer. Elle ne diffère donc de la version "stable" que le temps de quelques tests.

La version de développement

Les derniers développements collaboratifs autour d'openESub sont contenus sur un serveur CVS central qui comporte deux branches :

- une branche "stable" qui n'évolue qu'au travers de la correction de bugs ;

- une branche "instable" qui inclue toutes les nouveautés, modifications... et probablement aussi erreurs et bugs.

Evolutions entre les versions

Cas simple : correction d'un bug sur la version de production

Plutot que de faire de grands discours, un exemple sera plus clair :

- A l'instant t, la version "stable" et la version "testing" sont parfaitement identiques ;

- A l'instant t+1, on decouvre un bug, rapidement corrigé dans le CVS (branche stable), ce qui n'a aucun impact sur les versions "stable" et "testing" installées sur le serveur public ;

- A l'instant t+2, on synchronise la version "testing" du serveur public avec le CVS (branche stable), la version "testing" n'est donc plus concernée par le bug ;

- A l'instant t+3, si la modification apportée à "testing" n'a pas d'effets pervers non prévus initialement (pour savoir cela, on n'a besoin des tests de la communauté), on "release" une nouvelle version en incrémentant le chiffre z ;

- A l'instant t+4, on synchronise la version "stable" avec la nouvelle release numérotée donc x.y.z+1 (cette dernière est alors en outre immédiatement téléchargeable sur http://www.openesub.org/pub/releases/stable)

A chaque changement de la version de production, on a donc nécessairement un numéro de version différent.

Autres cas

Pour les petites évolutions fonctionnelles (ne nécessitant pas la modification du schéma de la base), on utilisera le même principe. S'il faut modifier la structure de la base de données par contre, ce n'est pas possible puisque la version "testing" pointe vers la même base que la version "stable". On procèdera donc différemment en choisissant une procédure adaptée au cas précis.

Aide mémoire pour les administrateurs

Synchroniser la version "testing" par rapport au CVS (branche stable)

- se loguer en openesubtests

- se placer dans scripts/

- lancer ./cvs_jeu_maj.sh

Sortir une nouvelle release

- se loguer en openesubtests

- se placer dans scripts/

- lancer ./release.sh x.y.z

(à ce point là, la release n'est ni installée sur la version "stable", ni téléchargeable publiquement)

Installer une nouvelle release

- se loguer en openesub

- se placer dans scripts/

- lancer ./get_release.sh x.y.z

(à ce point là, le release est installée sur la version "stable" et elle téléchargeable publiquement)

Outils personnels