alphas, betas, code freeze avant janvier prochain

Équipes maintenance
#1

Si on s’en tient au planning, SPIP4.4 et SPIP5.0 sortiront fin janvier 2025, soit, dans 4 mois.

  • Est-ce qu’'on prévoit des 4.4-alpha et 5.0-alpha ?
  • Est-ce qu’on prévoit un « code-freeze » avec une 4.4-beta et une 5.0-beta ?

Pour la sortie de la 4.3 cet été, on a fait ça et ça a pas trop mal marché.

Le principe, grosso modo basée sur l’hypothèse suivante :

Sortie de SPIP4.4-beta1 et SPIP5.0-beta1 le 20 décembre, soit dans 3 mois environ et un mois avant la sortie des versions stables 4.4.0 et 5.0.0.
À partir de cette date, on ne traite que les bugs existant ou qui nous serons remontés par des testeureuses.
On ne traite plus les améliorations qu’on décale à une prochaine version (la 5.1, prévue pour juillet 2025)

Avant cela, on peut sortir une série de versions « alpha », par exemple 1 mois avant la date des « beta » et du « code-freeze », disons, au pif, le 29 novembre.
À partir de cette date, le périmètre définitif commence à se fixer, mais on peut encore ajouter des trucs relativement faciles ou simples à intégrer.

Pour vous donner une idée de l’état actuel du développement de SPIP4.4 et SPIP5 :

Il est possible de filtrer en fonction des milestones, des labels, etc.

Reste à décider si on renouvelle ce mode de stabilisation et les dates associées (à discuter).

Sortie de versions beta et code-freeze
  • oui
  • non

0 votant

Sortie de versions alpha
  • oui
  • non

0 votant

1 « J'aime »
CR Maintenance d'octobre en préparation
#2

ca me parait très bien d’avoir un code freeze, ca permettra de savoir facilement si on peut passer des plugins en compta 5.0, puisqu’on sera alors définitivement ce qui est cassée grace au magnifique fichier UPGRADE_5_0.md.

On pourrait même imagine d’avoir un petit script bash (ou php) qui grep sur tout un repertoire pour rechercher les noms des fichiers/variables/truc supprimés et dire « si tu veux rendre compatible, faut adapter ca ».

2 « J'aime »
#3

Et un début de script Check compatibilité 5.0 ($13) · Extraits de code · GitLab

il faut compléter en reportant UPGRADE_5.0.md · master · spip / spip · GitLab dedans, mais voilà, l’idée est là

#4

Bonne initiative ça.
Tu publierais ça où au final, en tant que ce snippet ou dans un dépôt ?
Ça mériterait de rejoindre les infos de mise à jour en tout cas, même si ça ne concerne que le développement de plugins.

#5

no sé ^^ sans doute dans spip-contrib-outils

#6

Pour la beta et le code-freeze, je ne vois que des aspects positifs, ça permet de se focaliser sur la seule qualité de la release.

Par contre, pour la version alpha, autant je pense que c’est une bonne pratique, autant dans les faits je m"interroge - d’où le fait que je n’ai pas voté ; quels ont été les retours lors de la sortie de la précédente version ?

1 « J'aime »
#7

J’avoue que j’ai déjà oublié :confused:

@b_b , @marcimat ?

#8

Alors, après consultation de mon historique de stats, il y a eu des 4.3.0-alpha installées sur des sites vérifiés. Mais peu de retours formels ici sur ce forum ou à travers des issues, sauf erreurs de ma part.

Cocasse : Sortie de SPIP 4.3.0-alpha - SPIP Blog. Quelques commentaires où on nous dit que « les gens » préfèrent attendre

Ci-dessous tous les tags git « alpha » de spip/spip (et parfois, encore installées) :

v3.0.0-alpha.1 (juillet 2011)
v3.1.0-alpha
v3.2-alpha.1
v3.2.0-alpha.1 → Statistiques versions SPIP et plugins
v4.0.0-alpha → Statistiques versions SPIP et plugins
v4.1.0-alpha
v4.2.0-alpha, v4.2.0-alpha2 → Statistiques versions SPIP et plugins
v4.3.0-alpha
v4.3.0-alpha2

#9

Bah… quasi inexistants pour la 4.3 … ce qui ne veut pas dire que ce serait pareil pour la suite.

#10

Ouais il y a toujours un peu de version temporaire installée. C’est d’ailleurs pour cela que dans SVP le tableau des min/max parfois indique une version pré-finale.

#11

Version alpha, en effet, je ne pense pas qu’on attire foule de personnes prêtent à se frotter à la nouvelle mouture.

Autant mettre l’accent sur la publication de la beta, avec annonce publique qui sollicite des retours d’expérience, en étendant un peu la période entre beta et release, car 1 mois c’est vite passé. (enfin cette remarque valant surtout pour le saut de version majeure 4 → 5).

2 « J'aime »
#12

Je ne suis pas contre ça. On pourrait sortir une série de « beta » à partir de fin novembre ?

#13

ca me parait pas idiot, alpha fait plus peur que beta.

1 « J'aime »
#14

Vous, je sais pas, mais j’ai l’impression qu’on a fait le plein des votes sur ces 2 sondages.

Les mainteneureuses qui se sont abstenu·e·s jusqu’ici ne participent quasiment jamais aux discussions/décisions/releases … ou bien « ne se prononcent pas » …

Je rejoins celleux qui proposent de ne pas faire de versions alpha cette fois (et sans doute, je sais pas, de ne plus en faire dans le futur) et j’ai enlevé mon vote.

Je me tâte à clore les sondages, mais bon :slightly_smiling_face:

Sans augurer du résultat, parlons dates :

  • Combien de temps pour la période de « test » avec des pre-releases ? 1 mois avant release ? 2 mois ? plus ? moins ?
  • Si on ne fait pas d’alpha, on est toujours en phase pour le code-freeze à la sortie de la première beta ?
  • Bonus : Avez-vous une idée du nombre de pre-releases qu’il faudrait sortir ? qu’il ne faut pas dépasser ?
#15

1 mois et demi :slight_smile: (totalement pifométrique, ça fait la première beta à mi-décembre)

Oui. code-freeze / feature-freeze.

Aucune idée. Je crois qu’on n’a pas assez de retours utilisateurices pour juger. À la louche, je dirai au grand max 3 beta, ce qui ferait une pre-release toutes les deux semaines en moyenne. Si on a des retours utilisateurices…

#16

La dernière fois on a publié l’alpha 1 mois avant l’unique beta, donc on pourrait sortir une beta1 2 mois avant la release et la beta2 1 mois après celle-ci, ça revient au même sauf qu’on ne fait que changer le nom des releases :stuck_out_tongue: Au final je me demande si c’est pas plus clair d’avoir une alpha et une beta, et je ne suis pas certain que ça changerait grand chose dans le « taux d’adoption/test » qu’on appelle l’alpha une beta1.

Oui.

Si tu parles toujours des alpha/beta, pour 2 suffisent, on n’a pas assez de temps ni d’énergie pour faire plus.

Peut-être qu’on pourrait éviter de se prendre la tête en copiant ce qui se fait chez PHP ? De ce que je lis ici PHP 8.3 Beta Released • PHP.Watch il y a un beta, puis une RC et zou. Ces termes seraient peut-être plus rassurants pour le public ?

1 « J'aime »
#17

Oui, tous les tags qu’on peut faire avant les 4.4.0 et 5.0.0 : alpha, beta, RC (!), sont des pré-releases.

Pour une stable fin novembre, PHP sort :

  • les premières alpha dès juillet (ça peut aller jusqu’à 6 parfois), avec les premières images offficielles docker en bonus,
  • des beta en septembre (en général 3 ou 4),
  • des RC dès octobre (autant que nécessaire) , pendant 2 mois jusqu’à la stable
#18

Je crois que ces notions d’alphabétas échappent complètement aux utilisateurs, et qu’il ne faut pas compter sur leur retour.
Quant aux retours d’utilisateurs un peu avancés (j’essaie de rester dans ce groupe tant bien que mal) qui n’ont pas le nez collé sur les logs de commits mais qui sont en mesure de tester une release, il faut leur laisser un peu de temps si vous voulez vraiment un retour.

Je pense que la question est là : quels retours attendez vous, et quels moyens vous donnez vous pour ça.

Et si c’est trop compliqué, en temps à y investir, autant sortir directement la release finale directement sans perte de temps, non ?
Quitte à sortir dans la foulée une version corrective, mais on commence à être habitués aux rolling releases donc c’est pas forcément un problème.

1 « J'aime »
#20

Le réflexe d’imitation n’est pas toujours inspiration à suivre et faut surtout faire ce qui convient à SPIP et à ses utilisateurs. C’est une question à laquelle sans cesse revenir pour ceux qui sont habitués à baigner dans un bain professionnel qui valorise certaines pratiques et en dévalorise d’autres.

Mais une beta et éventuellement une alpha ou une RC me semblent une ou des bonnes pratiques pour la qualité de la release qui suit et notamment pour étendre la compatibilité d’un plus grand nombre plugins. Car une release sans bug mais sans plugins ne sert à rien.

Il faut donc voir comment faire pour que ça soit pleinement utilisé et que ça produise des retours.
2 idées :

  • documenter les points de tranquillité a priori et les points de vigilance à tester particulièrement.
  • les mettre en œuvre sur les sites de la galaxie (ou certains) et communiquer la dessus (double effet de tester et encourager à tester)
2 « J'aime »
#21

Je suis toujours favorable au code-freeze, et je proposerais bien une sortie d’une seule beta genre 6 à 8 semaines avant la sortie finale, avec la possibilité d’en proposer une seconde si les premiers retours sont nombreux et donnent lieu à autant de corrections.

1 « J'aime »