Geckozone

Différence entre trunk et branch ?

Le tronc (ou trunk) désigne le code principal de Gecko, le moteur de rendu sur lequel sont basés tous les programmes de la fondation Mozilla (Firefox, Thunderbird et la suite Mozilla). C'est sur ce tronc que travaille la majorité des développeurs.

A l'approche d'une nouvelle version majeure, une branche (ou branch) est créée. Lors de la création de la branche, le tronc est gelé (freeze), ce qui signifie que les modifications du tronc sont interdites sauf approbation des responsables (cela afin de ne pas compromettre la stabilité de la future branche). Le code présent dans le tronc est alors copié en totalité dans la branche (tronc et branche évolueront donc en parallèle) et un petit groupe de développeurs est détaché pour peaufiner le code source de la branche jusqu'à la sortie des versions définitives. Lorsque le tronc est réouvert (donc la branche créée), les modifications du tronc peuvent reprendre normalement. Dès la sortie des nouvelles versions, le groupe de développeurs affecté à la branche retourne travailler sur le tronc.

Pour clarifier un peu tout ça, prenons des exemples concrets :

>> La suite Mozilla 1.7.x est basée sur la branche Gecko 1.7, issue du tronc.
>> Firefox et Thunderbird 1.0.x sont basés sur la branche Aviary 1.0.1, issue de la branche Gecko 1.7.
>> Deer Park Alpha 1 (Gecko 1.8b2) et Alpha 2 (Gecko 1.8b3) sont basés sur le tronc.
>> Aux alentours du 26 Juillet prochain (si tout va bien ), une nouvelle branche sera créée et servira de base à Deer Park Beta (Gecko 1.8b4) et plus tard à Firefox 1.1.

Différence entre nightly et release ?

Une compilation nocturne (nightly build) représente une image à un instant donné de l'évolution du code (soit du tronc, soit d'une branche). Ce type de compilations est destiné prioritairement aux développeurs et testeurs et non au grand public. Ces compilations sont livrées sans garantie de fonctionnement et chacun les utilise à ses risques et périls.

Une version officielle (release) au contraire a fait l'objet de tests préalables et a été validée, garantissant une certaine stabilité et qualité de fonctionnement. Ce sont les seules compilations destinées au grand public.

Différence entre alpha, beta et release candidate (RC) ?

Le cycle de développement comprend plusieurs étapes distinctes:

versions Alpha: Ces versions apparaissent au début du développement. C'est durant cette période que sont ajoutées de nouvelles fonctionnalités et que le tronc ou la branche concernée subit ses plus profonds changements. Les versions Alpha sont donc davantage sujettes à l'instabilité et déconseillées au grand public.

versions Beta: A ce stade, les fonctionnalités principales sont toutes définies et ne devraient plus évoluer. Les développeurs se concentrent alors sur la correction des bugs.

versions RC (ou Release Candidate): Littéralement, ce terme désigne une version candidate au statut de finale. Autrement dit, si aucun bug majeur n'est détecté, celle-ci deviendra la version finale.

Plus d'infos:
Le processus de développement expliqué par Asa Dotzler
La branche 1.8 expliquée par Mozillazine (en français)
La branche 1.8 expliquée par Mozilla Developer News
La roadmap expliquée par Brendan Eich (l'inventeur du JavaScript c'est lui )
Cette même roadmap présentée par Mozillazine (en français)

En espérant clarifier un peu les choses
Si vous trouvez des erreurs, n'hésitez pas à les signaler.

Génial cette explication...

euh... pour les admins, ce post pourrait-il faire l'objet d'un article sur le portail ?

chBok a écrit : euh... pour les admins, ce post pourrait-il faire l'objet d'un article sur le portail ?

j'ai transmis la demande.

Un explication très clair, merci.
Je comprend mieux le fonctionnement du développement maintenant.

J'ai rajouté un petit paragraphe sur les versions Alpha, Beta et Release Candidate (rc)

L'article de MozillaZine-US indiqué existe en français à l'heure où j'écris :

Publication des plans de la ramification Gecko 1.8

Mozinet a écrit :L'article de MozillaZine-US indiqué existe en français à l'heure où j'écris :

Publication des plans de la ramification Gecko 1.8

Modifié. Merci

chBok a écrit : euh... pour les admins, ce post pourrait-il faire l'objet d'un article sur le portail ?

En tous cas la qualité du post de Ptit Lutin est appréciée. Et c'est tant mieux.

Attention quand même, Gecko n’est qu’un des nombreux composants de Mozilla, pas Mozilla à lui tout seul.

C'est plus qu'un composant, c'est LE coeur de mozilla... Tout le reste tourne autour de cela, si ce n'est bugzilla...

j'ai compris la différence entre tronc et branche (en fait, j'avais déjà compris), mais ce que je ne comprend tjs pas, c'est ce que deviennent les nouveautés d'1 branche ?

C'est elle qui devient le nouveau tronc ?
Ou le tronc reprend t'il les nouveautés de la branches ?
Et quand "dégèle" t'on le tronc ?

Il faudrait étoffer ce post pour le publier sur le portail

Anonymous a écrit :j'ai compris la différence entre tronc et branche (en fait, j'avais déjà compris), mais ce que je ne comprend tjs pas, c'est ce que deviennent les nouveautés d'1 branche ?

C'est elle qui devient le nouveau tronc ?
Ou le tronc reprend t'il les nouveautés de la branches ?
Et quand "dégèle" t'on le tronc ?

A mon avis la nouveauté est aussi intégrée au tronc mais une branche ne devient pas le tronc

C'est elle qui devient le nouveau tronc ?

Non. Comme précisé dans le premier post, tronc et branche évoluent parallèlement, ce qui signifie qu'ils ont chacun leur propre existante. Ainsi certaines corrections de bugs se font sur le tronc et pas sur la branche et inversement.

que deviennent les nouveautés d'1 branche ?
Ou le tronc reprend t'il les nouveautés de la branches ?

Les corrections effectuées sur la branche sont répercutées vers le tronc lors d'une synchronisation. La date de cette synchronisation n'est pas connue (peut-être lors de la sortie de Firefox 1.1/Thunderbird 1.1).

Et quand "dégèle" t'on le tronc ?

Lorsque la branche est créée.

Toto a écrit :Il faudrait étoffer ce post pour le publier sur le portail

Je vais essayer. Le tout est de ne pas perdre en clarté