Envole

h1. Cycle De Publication

h2. Établissement d'un calendrier

La feuille de route est planifiée pour l'année scolaire à la rentrée de septembre.

La publication des paquets en stable s'effectue une semaine avant que la première zone soit en congés.

Ce qui permet de ne pas prendre au dépourvu les établissements à la rentrée de chaque vacances.

Le délai entre une publication de paquet en candidat (RC) et une publication de paquet en stable est d'au moins 15 jours pour laisser remonter d'éventuelles demandes.

h1. Cycle normal

h2. Publication de paquets candidats

h3. On approche d'une publication de paquets candidats

Environ une semaine avant la date :

* ventiler les demandes, les demandes qui ne seront pas résolues dans la semaine sont reportées à la prochaine publication

* envoyer un courriel sur dev-envole pour demander aux développeurs de pusher leur travail

h3. Jour de la sortie des paquets candidats

* Ventiler les demandes, les demandes qui ne sont pas résolues sont reportées à la prochaine publication

* Reprendre les commits des développeurs (branche nickname/2.2 ou nickname/master) et les intégrer à la branche stable (2.2 ou master) en s'appuyant sur la feuille de route

* Compiler tous les paquets nécessaires en s'appuyant sur la feuille de route

* Relever les versions des paquets (telles qu'elles apparaissent lors d'un @Query-Auto -C@)

* Mettre à jour la page http://dev-eole.ac-dijon.fr/projects/envole/wiki/Diffusion pour 2.2 ou http://dev-eole.ac-dijon.fr/projects/envole/wiki/Diffusion23 pour 2.3

* Rédiger une annonce sur la page http://dev-eole.ac-dijon.fr/projects/envole/news

* Fermer les demandes relatives à cette feuille de route

* Écrire un courriel aux listes dev-envole, scribe, CLOE, pour informer de publication de la mise à jour (attachment:Exemple_de_mail)

* Passer la roadmap au statut *Fermée*

h3. Période de stabilisation des paquets candidats (plus ou moins 15 jours)

* Installer les paquets candidats dans les établissements pilotes après demande explicite à l'établissement

* Ouvrir de nouvelles demandes si besoin

* Corriger sur la branche stable (2.2 ou master) toutes demandes portant sur ces paquets candidats avant leur sortie en stable

* Les développements n'ayant rien à voir avec la feuille de route ne doivent ni être fait dans la branche stable ni être mergés, la branche est figée (période de freeze)

* Rédaction de la documentation en rapport avec les modifications publiées

* Traiter les demandes de la prochaine publication de paquets candidats

h2. Publication de paquets stables

h3. Jour de la sortie des paquets stables

* Recompiler tous les paquets nécessaires en *Security* en s'appuyant sur la feuille de route

* Relever les versions des paquets

* Mettre à jour la page http://dev-eole.ac-dijon.fr/projects/envole/wiki/Diffusion pour 2.2 ou http://dev-eole.ac-dijon.fr/projects/envole/wiki/Diffusion23 pour 2.3

* Rédiger une annonce sur la page http://dev-eole.ac-dijon.fr/projects/envole/news

* Fermer les demandes relatives à cette feuille de route

* Demander la synchronisation entre les dépôts test-eole et eole

* Écrire un courriel aux listes dev-envole, scribe, CLOE pour informer de la publication de la mise à jour (attachment:Exemple_de_mail)

* Passer la roadmap au statut *Fermée*

* Tagguer la branche stable des sources des paquets avec le nom de la roadmap (la branche dist/ubuntu/lucid/master est tagguée automatiquement lors de la compilation)

* Maintenir la liste des versions d'applications sur la page : http://dev-eole.ac-dijon.fr/projects/envole/wiki/CorrespondancePaquetsEnvoleDepotsGit

h1. Cycle exceptionnel

h3. Mise à jour en security

* Faire la correction

* Tester la correction en faisant un paquet de dev

* Recompiler le paquet en security

* Demander la synchronisation entre les dépôts test-eole et eole

* Maintenir la liste des versions d'applications sur la page : http://dev-eole.ac-dijon.fr/projects/envole/wiki/CorrespondancePaquetsEnvoleDepotsGit