Pour faire un release (ou un release candidate)

Notez que ceci s'applique aussi bien à AlternC qu'aux autres packages.

1. la version du package est mise-à-jour dans debian/changelog avec des notes sommaires, se basant sur les bogues résolus et la raison première du release (ne pas oublier de committer)
2. le package est construit (voir ConstructionPackage) et testé
3. Tagger les sources (svn cp https://dev.alternc.org/svn/alternc/trunk https://dev.alternc.org/svn/alternc/tags/0.9.6.3)
4. le package est publié sur alternc.org (par exemple, PublierAvecDput)
5. une annonce est envoyée sur users@ et dev@, et la page WikiStart est mise à jour
6. le "milestone" Trac est fermé et les bogues toujours ouverts de ce release sont repoussés à une version ultérieure, et la version est ajoutée à Trac (normalement, cette étape s'exécute automatiquement lors du tagging du release, mais il est bon de vérifier)

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

Étapes à faire pour faire un release

(Note: ces procédures ne sont pas vraiment utilisées. On essaie de faire des releases réguliers lorsque c'est pertinent (bogue de sécu, etc). Une autre façon de voir ça est que tous les releases, ces temps-ci, sont des RC de la 1.0...)

• longtemps *avant un release*, un bug est créé pour le représenter
  • le responsable du bug devient responsable du release
  • les bugs devant être résolus pour ce release doivent être marqués 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-même