Processus de publication d’une release

Publier une nouvelle version d’Elgg.

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

Pré-requis

  • Accès SSH à elgg.org
  • Accès aux commits sur http://github.com/Elgg/Elgg
  • Accès admin à https://elgg.org/
  • Accès au compte Twitter Twitter account
  • Node.js et Yarn installés
  • Sphinx installé (easy_install sphinx && easy_install sphinx-intl)
  • Client Transifex installé (easy_install transifex-client)
  • Compte Transifex avec accès au projet Elgg

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 ou plusieurs autre(s) dev(s).

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.

Première nouvelle version mineure/majeure stable

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

Update the README.md file badges to point to the correct new release numbers.

Préparer la sortie

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.

Installez les pré-requis :

yarn install elgg-conventional-changelog
easy_install sphinx
easy_install sphinx-intl
easy_install transifex-client

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.

Next, manually browse to the /admin/site_settings page and verify it loads. If it does not, a language file from Transifex may have a PHP syntax error. Fix the error and amend your commit with the new file:

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

Ensuite, soumettez un 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

Tagguez la release

Une fois approuvée et fusionnée, tagguez les release :

git checkout release-${version}
git tag -a ${version} -m'Elgg ${version}'
git push --tags origin release-${version}

Ou créez une release sur Github

  • Allez sur les releases
  • Cliquez sur “Create 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 tel que “Elgg {version}”
  • Collez la partie de CHANGELOG.md relative à cette release dans la description

Un peu d’administration pour finir

  • 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

Mettez à jour le site web

Construisez le package zip

Utilisez elgg-scripts/build/elgg-starter-project.sh pour générer le fichier .zip. Exécutez sans argument pour voir son utilisation.

# login as user deploy
sudo -su deploy

# regular release
./elgg-starter-project.sh master 3.0.0 /var/www/www.elgg.org/download/

# MIT release
./elgg-starter-project.sh master 3.0.0-mit /var/www/www.elgg.org/download/

Note

Pour les releases Elgg 2.x utilisez la branche 2.x du starter-project (par ex. ./elgg-starter-project.sh 2.x 2.0.4 /var/www/www.elgg.org/download/)

  • Vérifiez que vendor/elgg/elgg/composer.json dans le fichier zip a bien la version attendue.
  • Si ce n’est pas le cas, assurez-vous que GitHub a bien le tag de release, et que le projet de démarrage a un élément compatible elgg/elgg dans la liste « requires » de composer.

Construire les packages zip 1.x

Utilisez elgg-scripts/build/build.sh pour générer le fichier .zip. Exécutez sans argument pour voir L’utilisation.

# regular release
./build.sh 1.12.5 1.12.5 /var/www/www.elgg.org/download/

# MIT release
./build.sh 1.12.5 1.12.5-mit /var/www/www.elgg.org/download/

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
  • Committez et poussez les modifications (push)
  • Mettez à jour le plugin sur www.elgg.org
composer update elgg/community

Mettre à jour elgg.org

composer update
  • Committez et poussez les modifications (push)
  • Faites un pull vers le site en activité
cd /var/www/www.elgg.org && sudo su deploy && git pull
  • Mettez à jour les dépendances
composer install --no-dev --prefer-dist --optimize-autoloader
  • Allez sur la panneau admin de la communauté
    • Vider le cache APC
    • Exécuter la mise à niveau

Faites l’annonce

Ce 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 d’Elgg