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

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

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"1 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 :

La plate-forme technique de Zeste de Savoir sera maintenant numérotée {année}.{mois}, sans zéros facultatifs. Exemple : v15.5.

En cas de plusieurs sorties majeures le même mois2 : {année}.{mois}.{séquence}. Exemple : v15.5 (sous-entendu .0) puis v15.5.1

En cas de hotfix, on conserve la notation lettrée actuelle {année}.{mois}.{lettre}, la lettre commençant à b (la version a étant la version normale). Exemple : v15.5b, voire v15.5.1b.

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 ?


  1. En général "trop", d'ailleurs. 

  2. Ce qui est rare, ça n'est arrivé qu'une fois jusqu'ici. 

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

Doctorant et assistant en chimie à l'Université de NamurEx-dev' pour ZdS (a aidé à réaliser la ZEP-12 !) • Carniste cis (y parait que c'est une injure)

+0 -0
Staff

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.

+2 -1

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)

Édité par Wizix

Mon projet : OpenPlane, un utilitaire en Java pour les pilotes, les vrais !

+1 -0
Staff
Auteur du sujet

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

Édité par Alex-D

Staff

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.

+1 -0

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 :)

Happiness is a warm puppy

+4 -0

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} !

Médicament flemmard aux pul(p)sions imprécises. “Don’t wait for the perfect moment. Take the moment and make it perfect.”

+2 -0
Staff

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 ?

Staff

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

La beta ?

Kje

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 ?

Happiness is a warm puppy

+0 -0
Staff

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. :)

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

SpaceFox

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.

Staff
Auteur du sujet

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.

Édité par SpaceFox

Staff

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.

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte