Avec comme objectif de livrer les nouvelles fonctionnalités, les augmentations des performances, les mises à jour de sécurité et les améliorations de la stabilité aux utilisateurs plus rapidement, Mozilla a décidé de migrer vers un cycle de développement rapide. Pour ce faire, Mozilla a non seulement décider de sortir les nouvelles versions finales sur un rythme accéléré, mais aussi de décaler dans le temps le développement des nouvelles versions qui sont délivrées aux testeurs sur différents canaux de distribution disponibles simultanément. Un canal Aurora est aussi ajouté pour permettre aux testeurs de découvrir les nouvelles fonctionnalités de la prochaine version majeure de bonne heure avec un minimum d’assurance qualité et une stabilité et un parachèvement croissant au fur et à mesure des mises à jour du canal.

Pour plus de détails sur ce processus, voyez ci-dessous la traduction de ce billet de Christian Legnitto sur Mozilla Developer News.

Aurora est disponible en français.

Télécharger Mozilla Aurora en français

Logos Aurora Nightly Beta

crédit Mozilla

Traduction du billet de Christian Legnitto sur Mozilla Developer News :
New development channels and repositories for rapid releases ;
relecture par Bruno Ethvignot

De nouveaux canaux et dépôts de développement pour des sorties rapides

Récemment, nous avons annoncé des détails supplémentaires sur les canaux pour le nouveau processus de développement et de publication de Firefox. Nous sommes convaincus que ce processus nous permettra de livrer des versions de Firefox de qualité aux utilisateurs à une cadence plus rapide et nous vous demandons d’être patient pendant que nous mettons au point les derniers éléments restants.

Raisonnement derrière les nouveaux canaux et dépôts de mise à jour

Firefox dispose actuellement de trois canaux de mise à jour, qui contiennent tous des mises à jour compilées à partir du même dépôt de code :

  1. Nocturne (Nightly) – versions créées à partir du dépôt mozilla-central chaque nuit. Celles-ci ne sont pas qualifiées par l’assurance qualité (QA).
  2. Bêta (Beta) – versions créées à partir du dépôt mozilla-central, qualifiées par la QA comme étant de qualité suffisante pour être communiquées aux utilisateurs bêta.
  3. Sortie (Release) – versions créées à partir du dépôt mozilla-central, qualifiées par la QA comme étant de qualité suffisante pour être communiquées à des centaines de millions de personnes.

Parce que les mises à jour que nous mettons sur le canal Nocturne ne sont pas testées avant d’être offertes aux utilisateurs, nous utilisons une icône et un nom différents (« Minefield ») pour indiquer qu’ils sont à risque et ne sont pas le Firefox stable que la plupart des utilisateurs attendent :

Minefield

Bien que cette approche nous ait bien réussi, nous estimons qu’il y a certains problèmes inhérents à la structure actuelle :

  1. L’attente de qualité pour les mises à jour sur le canal bêta est nettement plus élevée que pour les mises à jour sur le canal Nocturne.
  2. Les utilisateurs sur le canal bêta peuvent ne même pas savoir qu’ils sont en train d’exécuter une préversion (mais j’espère décente) de Firefox.
  3. À cause du n° 1 ci-dessus, le développement sur le dépôt mozilla-central est gelé pendant que nous stabilisons pour une mise à jour vers le canal Bêta. Cela provoque un retard accumulé énorme de correctifs et ajoute un risque supplémentaire pour la prochaine version bêta.
  4. Les tierces parties doivent suivre attentivement le développement de Firefox pour savoir quand une étape importante dont ils se soucient (comme quand les fonctionnalités sont au complet, le gel des API ou le gel des chaînes) est atteint.
  5. Pour les développeurs, les règles de l’arbre sont en constante évolution sur mozilla-central en fonction de quand nous avons livré une mise à jour à partir de celui-ci.

En raison de ces problèmes, nous sommes arrivés à un processus modifié :

Nouveau processus
  1. Nocturne (Nightly) – versions créées à partir du dépôt mozilla-central chaque nuit. Celles-ci ne sont pas qualifiées par la QA.
  2. Aurora – versions créées à partir du dépôt mozilla-aurora, qui est synchronisé à partir de mozilla-central toutes les six semaines1. Il y a une petite quantité de QA au début de la période à 6 semaines1 avant que les mises à jour soient proposées.
  3. Bêta (Beta) – versions créées à partir du dépôt mozilla-central, qualifiées par la QA comme étant de qualité suffisante pour être communiquées aux utilisateurs bêta.
  4. Sortie (Release) – versions créées à partir du dépôt mozilla-central, qualifiées par la QA comme étant de qualité suffisante pour être communiquées à des centaines de millions de personnes.

Avec la nouvelle structure, tous ces problèmes s’en vont :

  1. L’attente de qualité pour les mises à jour sur le canal bêta est nettement plus élevée que pour les mises à jour sur le canal Nocturne.

    Nous résolvons ce problème en créant le canal Aurora. Ce canal a des attentes de qualité plus élevées que le canal Nocturne, mais inférieures aux attentes du Bêta. Au début de la période Aurora de 6 semaines1 pour une version particulière, la qualité sera plus proche du canal Nocturne. À la fin de la période Aurora de 6 semaines, la qualité aura convergé pour correspondre à celle du canal Bêta.

  2. Les utilisateurs sur le canal bêta peuvent ne même pas savoir qu’ils sont en train d’exécuter une préversion (mais j’espère décente) de Firefox.

    Pour résoudre ce problème nous sommes en train de reconditionner les compilations à partir des canaux individuels avec de nouvelles icônes. Cela devrait permettre aux utilisateurs de savoir en un coup d’œil sur quel canal ils sont et de définir les attentes de stabilité en conséquence.

  3. À cause du n° 1 ci-dessus, le développement sur le dépôt mozilla-central est gelé pendant que nous stabilisons pour une mise à jour vers le canal Bêta. Cela provoque un retard accumulé énorme de correctifs et ajoute un risque supplémentaire pour la prochaine version bêta.

    Parce que nous utilisons un modèle de dépôt par canal, le développement de mozilla-central (et donc les mises à jour sur le canal Nocturne) n’auront jamais à geler… la convergence de la qualité a lieu sur les autres dépôts, pendant que le développement de Firefox se poursuit sur mozilla-central non affecté par le processus de publication.

  4. Les tierces parties doivent suivre attentivement le développement de Firefox pour savoir quand une étape importante dont ils se soucient (comme quand les fonctionnalités sont au complet, le gel des API ou le gel des chaînes) est atteint.

    Avec le nouveau processus ce qui arrive où et quand est beaucoup plus explicite et cohérent. Les tierces parties n’aurons plus à savoir que bêta 8 a été avec les API au complet tandis que bêta 9 a été avec les chaînes gelées. Au lieu de cela nous pouvons donner des garanties telles que « pas de nouvelles chaînes en-US seront ajoutées par le biais des mises à jour sur le canal Aurora » et « aucun changement de l’API des extensions ne sera délivré aux utilisateurs via le canal Bêta ». Cela permet aux tierces parties de planifier avec précision et incite à coller aux règles et au calendrier.

  5. Pour les développeurs, les règles de l’arbre sont en constante évolution sur mozilla-central en fonction de quand nous en avons expédiés en dernier une mise à jour depuis lui.

    Enfin, les nouveaux dépôts (qui correspondent aux canaux) permettent aux développeurs de faire ce qu’ils font le mieux – développer. Un développeur ne devrait plus avoir besoin de savoir que nous sommes en mode bloquant-uniquement pour une version particulière. Au lieu de cela, ils seront autorisés à déposer leurs corrections sur mozilla-central à tout moment à condition qu’ils respectent les règles de l’arbre de mozilla-central. Le dépôt mozilla-aurora aura des règles différentes et mozilla-beta aura des règles différentes (et plus strictes) encore. Les règles pour chacun de ces dépôts ne changeront pas au fil du temps ou d’une version à l’autre, ce qui devrait aider à soulager beaucoup de confusion et de gêne pour les développeurs.

Mécanique des dépôts et canaux

La mécanique des dépôts et des canaux peut être très spécifique et complexe. La plupart des développeurs ne feront pas attention aux détails et à la place se concentreront uniquement sur le dépôt de leurs correctifs sur mozilla-central. Si vous vous souciez des détails, veuillez jeter un œil au document précédemment publié sur les détails du processus. Le document est l’endroit où nous recueillons les décisions sur la façon de mieux gérer les rouages des versions.

Retours

Comme avec la plupart des changements de processus de Mozilla, questions et commentaires de la communauté sont fortement encouragés. Le meilleur endroit pour poser des questions est le groupe de discussion mozilla-dev-planning. Veuillez ne pas oublier de lire les discussions antérieures pour vous assurer qu’il n’a pas déjà été répondu à votre question car il y a déjà eu de bonnes discussions.

Les commentaires et modifications au document sur les détails du processus peuvent être soumises directement comme demandes de « pull » sur GitHub. Vous pouvez également utiliser la vue historique pour voir les itérations que le document sur le processus a déjà connu.

Enfin, je comprends qu’il y a beaucoup de détails dans le document des caractéristiques et qu’il est parfois plus facile de parler à quelqu’un directement. Je suis disponible via email et IRC (LegNeato sur irc.mozilla.org) pour tout membre de la communauté avec des questions ou des commentaires.


Note 1 : Veuillez voir le document sur les détails du processus les raisons pour lesquelles les étapes pour Firefox 5 ne sont pas en incréments de 6 semaines.

Certains droits réservés
Cette traduction est disponible sous licence Creative Commons
Paternité - Partage des conditions initiales à l’identique 2.0 France

Sources et références