When I get that “New Discourse version, update available” email from my forum (this time about 2.1.0.beta1), I know @jomaxro 's elaborate release notes will appear here within 6-24 hrs. or so. It’s not very important, but I would organize it in a different order.
1 « J'aime »
I agree, first thing I do is go and look at the release notes to determine whether or not I am going to apply the update.
2 « J'aime »
There is a high level release note list here: Discourse Version 2.1
1 « J'aime »
The notes are in the above topic, so this is covered.
I’m not seeing any notes specifically for 2.1b1. Just a general list of goals for the final version of 2.1.
I’m off today (family event), will respond to this properly next week. Short version: there are no major changes from the last release notes (2.0.0.beta10) and 2.1.0.beta1 - we simply pushed 2.0 to stable and moved work to 2.1.
4 « J'aime »
Ce message a été mis à jour pour la dernière fois 2021-06-28T04:00:00Z afin de détailler les processus actuels.
Bonjour à tous ! Plusieurs sujets à aborder ici, voyons si je peux tous les couvrir.
Il s’agit d’une décision délibérée de notre part. Nous n’avons pas de système de publication formel pour nos versions bêta. Nous publions une nouvelle version lorsque cela a du sens pour nous. Par conséquent, il y a généralement peu d’avertissement avant une publication, et donc peu de temps pour rédiger des notes de version. @codinghorror a estimé qu’il n’était pas logique de retarder une publication pour attendre que les notes soient prêtes.
Les versions bêta sont désormais coordonnées entre les équipes d’ingénierie et de la communauté. Les notes de version devraient être en ligne en même temps que les versions bêta, sinon peu avant.
Vous ne verrez pas de notes de version pour la bêta1. Pour éviter toute confusion, des notes de version sont rédigées pour toutes les versions bêta. Les versions stables recevront également des notes. Notez que la bêta1 (de n’importe quelle version) est pratiquement identique à la dernière bêta de la version précédente.
Pour comprendre pourquoi, je dois expliquer un peu comment nos branches sont configurées.
Pour nos besoins ici, nous devons connaître 4 branches de Discourse : main, tests-passed, beta et stable.
Main :
Lorsqu’un nouveau commit est ajouté à Discourse, il se trouve sur la branche principale. Main est la branche absolument la plus récente (la plus actuelle) de Discourse, et nous ne recommandons à personne d’exécuter son site en suivant la branche principale.
Tests-passed :
Lorsqu’un nouveau commit est poussé sur la branche principale, notre serveur de construction exécute automatiquement tous nos tests sur le dernier code. Une fois qu’ils sont tous réussis, le commit est ajouté à notre branche tests-passed. C’est la branche sur laquelle tous les sites Discourse s’exécutent par défaut.
Beta :
Toutes les quelques semaines, nous poussons les commits actuels de tests-passed vers beta. Nous utilisons bêta comme une « étape » pour publier un ensemble de commits que nous voulons que davantage de sites exécutent et testent. Nous publions également une bêta si nous avons une correction de sécurité importante que nous voulons que les sites reçoivent. Lorsqu’une bêta est poussée, tous les sites exécutant tests-passed ou beta reçoivent l’e-mail « nouvelle mise à jour disponible ». Les sites exécutant tests-passed se mettront à jour vers les commits actuels de tests-passed (y compris tous les nouveaux commits poussés après la bêta), tandis que ceux sur beta ne le feront pas.
Stable :
Tous les 4 à 6 mois, nous publions une nouvelle version stable. Environ 2 semaines avant de publier la version stable, nous publions notre dernière bêta. Nous surveillons ensuite nos journaux de près pour essayer de détecter tous les bugs persistants et éviter d’ajouter de nouvelles fonctionnalités ou des changements risqués. Une fois que nous sommes satisfaits de l’état de la bêta actuelle, nous publions en version stable.
En comprenant ce qui précède, utilisons 2.0.0 comme exemple. Nous avons publié 2.0.0.beta10 le 16 mai. Tous les utilisateurs exécutant tests-passed ou beta ont reçu un e-mail (et nous supposons qu’ils ont mis à jour). J’ai rédigé des notes de version pour cette bêta. Environ 2 semaines plus tard, le 31 mai, nous avons publié cette version en stable sous le nom de 2.1.0. Pour garantir que les utilisateurs exécutant tests-passed ou beta reçoivent également la mise à jour, nous avons publié la même version sous le nom de 2.1.0.beta1.
Est-ce que tout cela a du sens ? Y a-t-il quelque chose que je pourrais faire différemment avec release-notes dans #feature:announcements pour rendre cela plus clair ?
20 « J'aime »