Convention de nommage des branches¶
Notre convention de nommage des branches garantit que les logiciels peuvent être construits par notre CI et testés facilement par d’autres développeurs.
Le fichier README de chaque dépôt Git doit indiquer la convention de nommage des branches utilisée et les écarts éventuels par rapport à la norme.
Paquets Click¶
Les logiciels distribués exclusivement sous forme de paquets click (et non sous forme de DEB) n’utilisent qu’une seule branche master qui est protégée. Des branches de développement temporaires séparées avec des noms descriptifs arbitraires peuvent être créées et fusionnées dans la branche master le moment venu. Idéalement, des étiquettes Git ou des versions GitHub devraient être utilisées pour marquer et archiver les étapes importantes de l’histoire du développement.
Paquets DEB¶
Pour nous aider à livrer notre code dans Ubuntu Touch aussi facilement que possible, notre CI construit automatiquement nos dépôts Git dans un certain nombre d’archives APT hébergées à http://repo.ubports.com/, en fonction du nom de la branche.
Nous maintenons les branches suivantes dans les dépôts Git :
branches GIT |
Description |
Archives APT correspondantes |
|
|---|---|---|---|
Nom |
Distribution de base |
||
|
Représente le dernier développement d’Ubuntu Touch. Tous les types de changements sont autorisés dans cette branche. |
|
Ubuntu LTS la plus récente ou à venir. |
|
Debian testing |
||
|
Représente le code d’une version majeure particulière. Elle se détache de la branche |
|
Ubuntu LTS au moment de la dérivation. |
|
Un cas particulier de |
|
Ubuntu 20.04 LTS. |
|
Branches qui utilisent le système obsolète des « extensions de branches » pour les modifications inter-composants. Leur utilisation n’est plus recommandée. |
|
Ubuntu 20.04 LTS. |
|
Toutes les autres branches peuvent être utilisées pour proposer des demandes de fusion ou pour d’autres raisons. Ces branches ne sont pas construites par l’IC à moins qu’elles ne soient proposées comme demande de fusion. |
N/A, sauf s’il est proposé comme RM contre les branches susmentionnées (voir ci-dessous). |
|
Pour s’assurer que la branche main ne manque aucun changement, tous les changements doivent être faits d’abord sur la branche main avant d’être rétroportés sur les branches des versions majeures. Une exception est faite lorsqu’un changement n’est plus applicable à la branche principale à cause d’autres changements dans cette branche.
Note
Si la prochaine version de développement n’est pas encore disponible pour les tests, et que vous avez besoin que le changement soit disponible pour l’installation pour les tests, il est permis de cibler temporairement le jeu de modifications sur la branche de la version majeure pour que les paquets soient construits avec cette version. Lorsque le jeu de modifications est prêt pour la fusion, il doit être redirigé sur la branche main.
Archives de l’APT pour les demandes de fusion¶
En plus des archives mentionnées ci-dessus, nous créons également des archives APT pour les RM effectuées sur nos dépôts Git. Cela nous permet de tester le résultat de la construction sur des appareils réels en utilisant ubports-qa avant de fusionner le code. Pour chaque MR, l’IC va compiler le code contre toutes les mêmes cibles que la branche cible de la MR, et va ensuite leur ajouter _-_PR_<nom du dépôt>_<numéro de la MR> [1]. Par exemple:
Un MR numéroté 100 fait sur la branche
maindu dépôt Gitlomiri(quand le LTS Ubuntu actuel estnoble) aura des archives APT nomméesdevel-noble_-_PR_lomiri_100etdevel-debian_-_PR_lomiri_100.Un MR numéroté 125 fait sur la branche
ubports/24.6.xdu dépôt Gitmorph-browseraura une archive APT nommée24.6.x_-_PR_morph-browser_125.