Processus de Release

Pour publier une nouvelle version de Yarn

  1. Assurez-vous que la branche master courante est verte sur Circle, Travis et AppVeyor
  2. Vérifiez que votre copie local de Yarn est à jour, puis lancez ./scripts/release-branch.sh. Cela créera une branche 0.xx-stable et assignera un tag 0.xx.0 au HEAD, puis publiera le tout sur git origin
  3. CircleCI et AppVeyor créeront automatiquement une release GitHub si le build passe. Ils vont builder les artefacts et les attacher à la release GitHub. Ils publieront également la nouvelle version sur npm avec le tag rc (cela signifie qu’elle ne sera pas installée par défaut par les utilisateurs, mais sera néanmoins disponible)
  4. Vérifiez que tous les artefacts sont attachés à la release (.tar.gz, .deb, .rpm et .msi). Ne continuez pas tant que cette étape n’est pas validée
  5. Générez une nouvelle release notes avec la commande git-release-notes v0.yy.0..v0.xx.0 markdown > release-notes.md utilisant l’outil git de release notes où v.0.yy.0 est le dernier tag stable. Les suggestions pour d’autres outils sont les bienvenues

Pour patcher une version existante de Yarn

  • Basculez sur la branche releasée git checkout 0.x-stable, par exemple 0.7-stable
  • Faites des cherry-pick des fix depuis la branche master
  • Taguez la nouvelle release avec npm version patch, ce qui va créer un commit avec le package.json modifié et le tag v0.xx.1 sur ce commit
  • Faites un push vers origin avec git push origin 0.x-stable --follow-tags

Pour marquer une release comme stable

  1. Supprimez le tag rc sur la release sur npm et mettez la version considérée comme stable à latest :
npm dist-tag rm yarn rc
npm dist-tag add yarn@<version> latest
  1. Mettez à jour latest_version dans _config.yml sur le site. Cela va mettre à jour les URLs de téléchargement (/latest.tag.gz, etc) pour pointer vers la nouvelle release. Cela va éventuellement être automatisé (#&87)
  2. Les repo Debian et CentOS devraient automatiquement être mis à jour avec la dernier release en moins de 5 minutes (gardez un oeil sur les commits)

Ancien Processus Manuel

C’est l’ancienne façon de faire des release, en guise de référence (dans le cas où l’automatisation casse). La construction d’une release se faisait en deux étapes - La plupart des choses sont construites sous Linux et certaines choses spécifiques à Windows (comme le Windows installer) sont construites sous Windows.

Sous Linux :

  1. ./scripts/release-branch.sh
  2. Construisez les packages Debian et RPM : ./scripts/build-deb.sh
  3. Attachez les fichiers .deb et .rpm depuis le répertoire artifacts à la release GitHub

Sous Windows :

  1. Construisez Yarn normalement (yarn install && yarn run build)
  2. powershell .\scripts\build-dist.ps1
  3. Construisez le Windows installer : yarn run build-win-installer - TODO: Ajouter la signature Authenticode pour l’installer (#619)
  4. Construisez le package Chocolatey : yarn run build-chocolatey
  5. Attachez le fichier .msi du répertoire artifacts à la release GitHub
  6. Uploadez le package Chocolatey (dans le future nous devrions automatisez ça). - Remarque : ne faites ça qu’une fois que le MSI est attaché à la release GitHub, étant donné que Chocolatey va récupérer le MSI via le lien de téléchargement - Notez également : la modification du MSI après avoir uploadé le package Chocolatey va casser le package Chocolatey, étant donné qu’il contient le hash du MSI. Assurez-vous de toujours uploader les deux en même temps !
← Traductions Gouvernance →