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¶
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
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 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
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.
Installez les pré-requis :
yarn install elgg-conventional-changelog
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 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, taguez la 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 “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
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 construire la nouvelle branche (et non la nouvelle balise)
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
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¶
ssh vers elgg.org
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.
Mettez à jour la page de téléchargement de elgg.org¶
Ajoutez la nouvelle version dans
classes/Elgg/Releases.php
Commitez et poussez les modifications
Mettez à jour le plugin sur www.elgg.org
composer update elgg/community
Mettez à jour elgg.org¶
Modifiez la version de Elgg requise dans
composer.json
Mettez à jours les vendors
composer update
Commitez et poussez les modifications
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é
Videz le cache APC
Exécutez la mise à niveau
Faites l’annonce¶
Ceci devrait être la toute dernière chose à faire.
Ouvrez
https://github.com/Elgg/Elgg/blob/<tag>/CHANGELOG.md
et copiez le contenu pour cette versionConnectez-vous sur https://elgg.org/blog et rédigez un nouvel article de blog avec un sommaire
Copiez le contenu dans le CHANGELOG, supprimez le formattage, et supprimez manuellement les balises SVG
Ajoutez les tags
release
etelgg2.x
où x est le nom de la branche en train d’être publiéeTweetez depuis le compte Twitter account de Elgg