Checklist

Pour faire un release (ou un release candidate). Notez que ceci s'applique aussi bien a AlternC qu'aux autres packages.

  1. Traduction: les TemplatesGettext? sont mis à jour et les équipes de traduction traduisent les chaînes manquantes
  2. Testing: un TestComplet est effectué sur le release
  3. Changelog: la version du package est mise-à-jour dans debian/changelog avec des notes sommaires, se basant sur les bogues resolus et la raison première du release (ne pas oublier de committer)
  4. Build & retest: le package est construit (voir ConstructionPackage) et testé une dernière fois
  5. Tag: les sources sont taggées dans le SVN 
    svn cp https://dev.alternc.org/svn/alternc/trunk https://dev.alternc.org/svn/alternc/tags/0.9.9
  6. Upload: le package est publie sur alternc.org (par exemple, PublierAvecDput)
  7. Annonce: une annonce est envoyée sur users@ et dev@
  8. Wiki: les pages du wiki pertinentes sont mises-à-jour, une page pour l'Errata est créée (habituellement vide, à moins que des bugs connus majeurs demeurent). Pages à mettre à jour présentement:
  9. Trac: le "milestone" Trac est fermé et les bogues toujours ouverts de ce release sont repousses a une version ultérieure, et la version est ajoutée a Trac (normalement, cette étape s'exécute automatiquement lors du tagging du release, mais il est bon de vérifier, par exemple: le plugin ne migre pas les bugs vers la prochaine version automatiquement.)

Rappel: voici les règles que nous suivons pour les numeros de version http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

Ancien process: Etapes a faire pour faire un release

(Note: ces procedures ne sont pas vraiment utilisees. On essaie de faire des releases reguliers lorsque c'est pertinent (bogue de secu, etc). Une autre facon de voir ca est que tous les releases, ces temps-ci, sont des RC de la 1.0...)

  • longtemps *avant un release*, un bug est cree pour le representer
    • le responsable du bug devient responsable du release
    • les bugs devant etre resolus pour ce release doivent etre marques comme bloquant le bug du release
  • on fait un release candidate (RC) avant le release
  • on attend une semaine
  • si des bugs critiques aparaissent, on fait un autre RC
  • si le RC est bon, on fait le release lui-meme