Changement de la numérotation de la plate-forme technique de ZdS

Bonjour à toutes et à tous,

Suite au débat qui a eu lieu dans l'article sur la sortie de ZdS 1.6 et 1.7, il apparaît que tout le monde a sa vision de ce que devrait être le numéro de version du site.

Bilan des courses, tiré de ce débat et de mes réflexions en mon for intérieur :

• Le système actuel {majeur}.{mineur} n'est pas satisfaisant :
  • On a pas de règle claire pour décider de {majeur}
  • On incrémente {mineur} toujours de la même manière, que la version contienne surtout des correctifs ou aussi des grosses améliorations (API, etc).
  • Tout le monde a sa propre idée de ce que devrait être {majeur}, donc on a des propositions toutes valides qui vont de "ne presque jamais le changer" à "le changer à chaque ZEP ou presque".
  • Le socle technique est numéroté, mais on communique ce numéro aux utilisateurs sur ce site (ce qui entretient la confusion entre ce socle et l'instance zestedesavoir.com).
• Un système classique {majeur}.{mineur}.{correctifs} correspond très mal à notre manière de fonctionner, puisque les releases sont faites "quand il y a suffisamment à mettre dedans"¹ et que ce système suppose que les releases sont basées sur des fonctionnalités.
• Au final, ce qui qualifie encore le mieux une release est encore sa date de sortie.

Voici donc ce que je propose :

Avantages :

• On sait directement de quand date la dernière version
• Plus besoin de se demander si c'est une version majeure, mineure ou que sais-je encore
• Pas de tentation de faire de la communication sur un numéro de version sans réelle signification : on fait la communication sur les fonctionnalités qui sont apparues (et comme ça, pas de jaloux) (et oui, je compte ça comme un avantage)

Des remarques ou des questions ?

Pour pour et pour ! Au moins, on arrêtera de se demander quand sortir la version 2.0 … Tant qu'on ne commence pas à se taper dessus pour faire des LTS, bien entendu (et je dis pas ça uniquement pour le parallélisme avec Ubuntu, ça pourrais s'envisager à très long terme).

Je suis globalement pour car c'est clairement l'outil le plus simple à gérer. MAIS

En cas de plusieurs sorties majeures le même mois

Le nommage par année est souvent lié à une volonté de rendre les release prévisible. Je sais que ubuntu sortira en avril et en octobre, que les versions LTS sont en avril…

Sur ZDS, notre charme est fait par l'équipe de dev qui peut avoir des pics de productivités et d'inactivités qui se suivent assez forts quand même. Il suffit de voir la v1.8 qui a été vendue au départ comme "une release technique pour passer à django 1.7.7." TU as été le premier à dire qu'il y avait "13 tickets de trop" dans cette release.

Il suffit aussi de voir le gros bolout qu'a été la 1.2 (avec la désinscription) parce que justement la désinscription prenait trop de temps et que les devs travaillaient sans relâche.

Il est aujourd'hui impossible de trouver un jeu de version majeur/mineur à cause des ZEP qui sont développés en parallèles. Je n'ai aps non plus envie de terminer comme chrome qui passe de la version 31 à 32 parce qu'il a arrondi le coin d'un bouton.

Bref, la solution de l'année, oui, mais faudra qu'on réussisse à trouver un rythme de release prévisible pour que côté utilisateur ils sachent de quoi il en retourne.

Je vote carrément pour aussi ! Je trouve ce système très efficace pour Ubuntu, j'espère qu'il marchera aussi bien ici ! (le +1 ne suffsait pas )

EDIT : Je réagis suite au commentaire d'Artragis. Oui pour Ubuntu ça permet de connaitre la prochaine release, c'est pratique, on sait quand elle sortira. Mais ici, et même si ce n'est pas régulier, ça permettra de connaitre la sortie de la dernière release. Ça ne me dérange pas plus que ça que ce ne soit pas régulier avec ce système. (Dur dur de s'exprimer clairement avec un portable)

mais faudra qu'on réussisse à trouver un rythme de release prévisible pour que côté utilisateur ils sachent de quoi il en retourne.

Comme tu le dis plus haut, c'est pratiquement impossible, puisque l'activité de développement elle-même est extrêmement volatile.

Rien n'empêche d'avoir :

1
2
3
4
5
6

15.4
15.6
15.6.1
15.6.2
15.6.3
15.9

S'il y a de l'inactivité, les versions ne se suivront pas, mais ça en devient logique puisque les versions sont en réalité des dates.

Personnellement je trouve ça assez déroutant comme numéro de version (étant habitué au format majeure/mineure/correctif) mais vu le projet ça me semble plutôt adapté.

Je proposerai bien la forme AA.MM (donc avec un zéro jusqu'en octobre) pour faire ressortir le côté date, justement.

Ca me semble parfaitement adapter a notre rythme de dev. Et la remarque d'artagis est pour moi hors contexte. Oui ubuntu fait ça mais pas pour les mêmes raisons. Soyons honnête, aujourd'hui il n'y a presque pas d'autres utilisateurs de notre base de code. Il y en a qu'une a ma connaissance et ils arriveront a suivre. Je vois pas de raisons de chercher a avoir des sortis prévisible. Pour un os ça se comprend, pour notre plateforme pas du tout. D'autant qu'actuellement ils peuvent pas non plus prévoir. C'est indépendant du style de numérotation.

Complètement d'accord, et complètement pour cette modification.

En fait à la lumière de cette proposition et en relisant le titre de sortie :

Zeste de Savoir passe en version 1.7

Je me suis dit mais ouais c'est dommage de dire "passe en version" même "marketinguement parlant" ça donne pas forcément envie de lire.

Au final, on aurait pu écrire : "Le site évolue, il se dote d'une API, mais pas que…"

Idem pour la ZEP 12 : "Découvrez la nouvelle façon d'écrire vos tutoriels, l'occasion de faire un point sur la vie de site" etc. etc.

Au moins ça supprime la tentation d'écrire des titres de ce genre, c'est plutôt cool

Je suis pour aussi !

Je plussoie lethom, si l'on met met deux chiffres pour le mois (par exemple, "01" pour janvier) ça montre bien que c'est le format {année}.{mois} !

L'idée de la date en soit est plutôt bonne. Cependant, il faut que la règle soit claire sur la date en question.

On a deux dates dans notre Workflow :

1. la date du lancement de la release (la date DR)
2. la date de la MEP ( DF = DR + ~14 jours )

Quelle est la date qu'on considère (La logique voudrait qu'on considère la date de la MEP puisque c'est à ce moment qu'on crée le tag) ? Si on part sur l'option 2, comment on appelle les versions déployées en préprod ?

Si on part sur l'option 2, comment on appelle les versions déployées en préprod ?

La beta ?

Si on l'appelle comme ça, on ne sait plus faire la différence entre une beta et une autre. Avec le système actuel on a l'habitude quand on déclare un bug, de mentionner la version en preprod touchée. Si on garde beta quoiqu'il arrive, on aura des confusions dans les issues. Il faudrait donc une appellation en préprod qui évolue au fil du temps aussi.

En préprod t'as juste besoin d'un identifiant technique non ? Genre le hash de commit ou un truc du style.

Comme en Java quand tu télécharges un jar en SNAPSHOT il a un identifiant interne mais toi tu t'en balances, tu sais juste que c'est la dernière version sur laquelle les mecs bossent, non ?

On peut très bien imaginer que les versions de release s'appellent beta-{année}.{mois}.{jour}.

En préprod t'as juste besoin d'un identifiant technique non ? Genre le hash de commit ou un truc du style.

Oui, on a déjà le hash du commit, mais c'est plus parlant de déclarer une issue avec mentionnant une version plutot qu'un hash de commit.

Yop, mais du coup l'année/mois/jour correspondrait à la date prévue pour la MEP et pas à la date du lancement de la release.

A chaque mise en pré-prod.

Yop, mais du coup l'année/mois/jour correspondrait à la date prévue pour la MEP et pas à la date du lancement de la release.

Dans ma tête, ça correspondait à la date du jour du tag :

• RC1 = beta-15.4.27
• RC2 = beta-15.4.30
• RC3 = beta-15.5.3
• prod = v15.5

PS : je ne suis pas totalement satisfait de cette numérotation pour les -RC, mais je ne trouve rien de plus intelligent.

J'aurai vu plutôt une numérotation en préprod qui dit en gros, "Voici la version qui va être MEP en mai 2015", ce qui donnerait :

• RC1 (en preprod) : v15.05 (même si on le déploie en preprod au mois d'avril on sait que c'est pour MEP dans 2 semaines pour mai)
• RC2 (en preprod) : v15.05.b
• RC3 (en preprod) : v15.05.c
• prod : v15.05.c

Je trouve ça moins prise de tête et plus lisible.

Avec -RC1 alors, les lettres sont pour les hotfix. Et la version finale n'a pas de marqueur particulier, par définition (c'est le cas aujourd'hui : v1.7-RC5 et v1.7 sont la même chose mais il y a bien 2 tags).

Avec RCx à la place des lettres en preprod, c'est encore plus lisible.