Processus de publication d’une nouvealle version - release

Publier une nouvelle version de Elgg.

Voici le processus suivi par l’équipe du noyau pour publier une nouvelle version de Elgg. Nous publions cette information dans un esprit d’ouverture, et pour faciliter l’intégration de nouveaux membres de l’équipe.

Pré-requis

Fusionnez les commits à partir des branches les plus basses

Déterminez la branche LTS. Nous devons fusionner tous les nouveaux commits jusqu’ici en passant par les autres branches.

Pour chaque branche

Vérifiez la branche, assurez-vous qu’elle est à jour, et créez une nouvelle branche de travail avec la fusion. Par ex. ici nous fusionnons les commits de la 1.12 dans la 2.0 :

git checkout 2.0
git pull
git checkout -b merge112
git merge 1.12

Note

Si elle est déjà à jour (aucun commit à fusionner), nous pouvons nous arrêter ici pour cette branche.

S’il y a des conflits, résolvez-les, git add ., et git merge.

Faites un PR pour la branche et attendez le résultat des tests automatiques et l’approbation par un autre développeur (ou plusieurs).

git push -u my_fork merge112

Une fois la fusion effectuée, nous répéterions le processus pour fusionner les commits de la 2.0 dans la 2.1.

Préparation pour la première nouvelle version stable mineure/majeure

  • Mettez à jour Politique de support pour inclure la date de la nouvelle date de version mineure/majeure et complétez les vides de la version précédente.

  • Mettez à jour les badges du fichier README.md pour indiquer les nouveaux numéros de version corrects.

Préparation pour une nouvelle version majeure

  • Modifiez la configuration Transifex pour pousser les traductions vers un autre projet

Préparez la publication

Faites un PR avec les mises à jour des traductions

Installez les pré-requis :

easy_install transifex-client
easy_install sphinx
easy_install sphinx-intl

Note

Sur Windows, vous devrez exécuter ces commandes dans une console avec des privilèges admin

Exécutez le script languages.php. Par exemple, pour extraire les traductions :

php .scripts/languages.php 3.x

Faites une demande de fusion -PR- avec les nouvelles traductions et faites-la fusionner avant l’étape suivante.

Ensuite, accédez manuellement à la page /admin/site_settings et vérifiez qu’elle se charge. Si ce n’est pas le cas, un fichier de langue de Transifex peut avoir une erreur de syntaxe PHP. Corrigez l’erreur et modifiez votre commit avec le nouveau fichier :

# only necessary if you fixed a language file
git add .
git commit --amend

Faites le PR de la version

Mettez à jour votre clone git local.

Fusionnez les derniers commits vers le haut en commençant par la branche supportée la plus basse.

Visitez https://github.com/Elgg/Elgg/compare/<new>...<old> et soumettez le PR si quoi que ce soit a besoin d’être fusionné plus haut.

Note

Sur Windows, vous devrez exécuter ces commandes dans une console avec des privilèges admin

Exécutez le script release.php. Par exemple, pour publier 1.12.5 :

git checkout 1.12
php .scripts/release.php 1.12.5

Ceci crée une branche release-1.12.5 dans votre repo local.

Ensuite, soumettez une demande de fusion -PR- via GitHub pour les tests automatisés et l’approbation par un autre développeur :

git push your-remote-fork release-1.12.5

Taguez la release

Une fois approuvée et fusionnée, créez une version sur GitHub :

  • Allez sur les releases

  • Cliquez sur “Draft a new release”

  • Saisissez la version

  • Sélectionnez la bonne branche (par ex. 1.12 pour une release 1.12.x, 2.3 pour une release 2.3.x, etc.)

  • Définissez le titre de la release comme “Elgg {version}”

  • Collez la partie de CHANGELOG.md relative à cette release dans la description

Note

GitHub est configuré pour écouter la création d’une nouvelle version afin de créer automatiquement la version ZIP de Elgg. Une fois la version créée, attendez quelques minutes et le ZIP devrait être ajouté à la version.

Un peu d’administration pour terminer

  • Marquez les jalons de release Github comme terminés

  • Déplacez les tickets non résolus des jalons publiés vers des jalons ultérieurs

Actions supplémentaires pour la première nouvelle mineure / majeure

  • Créez une nouvelle branche sur GitHub (par exemple 3.3)

  • Définissez la nouvelle branche comme branche par défaut (facultatif, mais suggéré pour les versions stables)

  • Configurez Read The Docs pour créer la nouvelle branche (pas le nouveau tag)

  • Configurez Scrutinizer pour créer la nouvelle branche

  • Vérifiez le projet de démarrage Elgg pour les pré-requis potentiels / modifications de configuration dans le composer.json

  • Ajoutez la nouvelle version mineure/majeure au référentiel Elgg/community_plugins afin que les développeurs puissent télécharger des plugins pour la nouvelle version

  • Mettez à jour la configuration de build pour Elgg reference (sur le serveur web Elgg.org)

# in the file /root/elgg-scripts/cron/make_reference
# set the main build branch to the correct branch
# make sure if you change the main build branch to add the previous branch to the other branches to build
# the new configuration will be applied by the daily cron

Action supplémentaire pour la première nouvelle majeure

  • Sur GitHub ajoutez une règle de protection de branche (par exemple 4.*)

  • Configurez Scrutinizer pour suivre les nouvelles branches principales (par exemple 4.*)

Mettez à jour le site web

Mettez à jour la page de téléchargement de elgg.org

  • Clonez https://github.com/Elgg/community

  • Ajoutez la nouvelle version dans classes/Elgg/Releases.php

  • Commitez et poussez les modifications

  • Téléchargez la version ZIP depuis GitHub

  • Chargez le ZIP sur le serveur web elgg.org

sudo mv ~/elgg-x.y.z.zip /var/www/www.elgg.org/download
sudo chown deploy:deploy /var/www/www.elgg.org/download/elgg-x.y.z.zip

Mettez à jour elgg.org

composer update
  • Commitez et poussez les modifications

  • Faites un pull vers le site en activité

sudo -su deploy
cd /var/www/www.elgg.org
git pull
composer install --no-dev
  • Allez sur la panneau admin de la communauté

  • Videz le cache APC

  • Exécutez la mise à niveau

Faites l’annonce

Ceci devrait être la toute dernière chose à faire.

  1. Ouvrez https://github.com/Elgg/Elgg/blob/<tag>/CHANGELOG.md et copiez le contenu pour cette version

  2. Connectez-vous sur https://elgg.org/blog et rédigez un nouvel article de blog avec un sommaire

  3. Copiez le contenu dans le CHANGELOG, supprimez le formattage, et supprimez manuellement les balises SVG

  4. Ajoutez les tags release et elgg2.x où x est le nom de la branche en train d’être publiée

  5. Tweetez depuis le compte Twitter account de Elgg