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 NPM 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

Mettez à jour les dépendances composer

Depuis Elgg 2.3, composer.lock est commité dans le dépôt. De ce fait, si n’importe laquelle des dépendances composer nécessite une mise à jour, exécutez composer update sur la branche correspondante et faites une demande de fusion avec un fichier composer.lock mis à jour. Ceci va exécuter la suite de test et s’assurer que les nouvelles dépendances ne cassent pas le build.

Fusionnez les commits à partir des branches les plus basses

Déterminez la branche LTS (actuellement 1.12). Nous avons besoin de fusionner tous les nouveaux commits jusqu’ici depuis 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 Politique de suport pour inclure la date de la nouvelle version mineure/majeure et complétez les vides de la version précédente.

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 :

npm 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.

Ensuite, naviguez manuellement jusqu’à la page /admin/settings/basic et vérifiez qu’elle se charge. Si ce n’est pas le cas, il se peut qu’un fichier de traduction issu de Transifex comporte une erreur de syntaxe. Corrigez l’erreur et amendez votre commit avec le nouveau fichier :

# 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.

Note

Si c’est la première fois que vous construisez une version sur le serveur, exécutez composer global require "fxp/composer-asset-plugin:^1.2.0". Ceci va vous garantir que vous pourrez télécharger les ressources bower pendant le processus de build.

    # login as user deploy
    sudo -su deploy

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

# MIT release
./elgg-starter-project.sh master 2.0.4-mit /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 comment l’utiliser.

# 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