Prochaine version de ZdS : v1.6 ou v2.0 ?

Salut les zestes !

Je peux déjà vous annoncer que la prochaine release de Zeste de Savoir, qui n'est pas encore prête, va être imposante : elle contient déjà 60 correctifs !

Actuellement on y trouve la première version de l'API, qui d'ailleurs détermine notre possibilité de lancer la release, puisqu'un problème bloquant s'y trouve encore (en phase de résolution, si j'en crois les derniers messages).

On a aussi la possibilité d'y intégrer le passage à Django 1.7 et Python 3 ! Il va de soit que si les 3 éléments (début de l'API, Django 1.7 et Python 3) sont de la partie, cette release s'appellera v2.0 !

Toutefois, vu l'ampleur de la chose, je sollicite votre avis sur ce point :

En gros, de ce que j'en vois mutualiser tout ça dans une très grosse release (si c'est possible) :

• Limite le nombre de release casse-gueule (API, puis Django 1.7, puis Python 3 – pas forcément dans cet ordre – = 3 moyens de se planter)
• Fait une release très lourde, donc longue à tester (la limite des 2 semaines serait annulée dans ce cas) et à mettre en prod
• Limite les différences monstrueuses entre les branches dev et prod et donc les merge/rebase foireux (exemple de la PR de passage à Python 3 qui va dégager quelques centaines de u'bidule' dans tout le code…)

Selon moi, il ne faut pas attendre les fonctionnalités (surtout si on a aucune idée de la date de leur merge). Si on est déjà à 60 tickets (j'ignore s'ils sont majeurs ou mineurs) on peut clairement lancer une release (s'il y a des ressources dispo pour les hotfix bien sur).

Choix cornéliens si l'en est. Pas facile à dire.

Déjà avant tout : le passage à Django 1.7 et Python 3 sera pret quand ? On a une idée ? Parce que tant que ce ne sera pas prêt, les commits vont s'accumuler.

L'experience passé aurait tendance à nous dicter de ne pas attendre… mais en meme temps tu as bien raison de pointer le fait que faire un seul gros chantier serait ptet plus simple

Je connais pas assez le projet mais juste en miroir des points que tu avances (dans la colonne cons du fameux yellow pad) je dirais que généralement, quand on release trop de chantiers à la fois c'est la foire.

Je rajouterai juste un point (en marge de la longueur des tests) c'est l’accroissement du temps de résolution des bugs.

C'est le syndrome du "ça marche pas, qu'est-ce-que j'ai changé récemment ? même si ça n'a aucun rapport".

Quand t'as modifié deux fichiers, même si a priori ils n'ont absolument rien à voir avec l'erreur (un fichier i18n ??? pas posssible. Ah bah merde c'est un soucis d'escaping… !) t'as vite fait de trouver.

Si t'as modifié 40 fichiers, avant que tu te rappelles que t'as modifié trois ligne dans un fichier i18n tu vas te retourner le cerveau dans tous les sens, faire des rebase inutiles, …

A l'échelle d'un projet c'est la même, sauf que là c'est pire, les gens peuvent potentiellement se tirer dans les pattes : "t'as changé quoi à l'API ?" "Rien !" "Nan mais ça peut pas être un problème client, j'ai rien modifié à ça", …

Le jeu en vaut peut-être la chandelle, mais c'est vraiment l'écueil principal que je vois à une release "en bloc". Ca mutualise plein de chose c'est vrai, mais ça rend parfois ténue la recherche des causes de bugs et de régressions, malheureusement :\

En toute sincérité, je suggérerais (si c'est possible), de faire deux versions différentes. Une première (v1.6) pour faire passer tous les correctifs de bogues et autres changements « mineurs » qui s'accumulent, et une autre séparée (v2.0) qui fasse passer les gros changements de fond. Et l'idéal, pour une question d'image, serait que la v2.0 soit concomitante avec la nouvelle page d'accueil (ZEP-04). Ça nous amènerait vers fin mars début avril et laisserait du temps pour bien tester les gros changements.

J'aurais pensé que la version 2 viendrait avec la version 1 stable de l'API, personnellement (donc pas uniquement le module membre) et potentiellement la ZEP 12. Mais c'est sans doute trop long terme x).

Disons que s'il y a zep 4, la v2 est logique, sinon 1.6, voire pour marquer le coup 1.6.42 histoire que les gens comprennent qu'il y a un gros coup de code quand même.

Je ne peux qu’appuyer ce propos. L’API, Django 1.7 et Python3 c’est important pour les développeur mais ça n’a aucun impact à court terme pour le visiteur moyen. Ce serait dommage de perdre le coup de pub version 2.0 si la réaction des gens est : « Ah en fait rien n’a changé ».

Alors oui je sais c’est un argument purement marketing bullshit mais on parle de numéro de version là. Je pense qu’on peut sacrifier la cohérence technique pour un peu de pub sur un truc aussi trivial.

Je rappelle que la question n'est pas le numéro de version. Qui d'ailleurs est un numéro de version technnique.

Vaut-il mieux, pour vous, lancer ces 3 gros chantiers en même temps, quitte à avoir une release un poil complexe à tester et installer ; ou les séparer dans plusieurs releases ?

Il est sans doute plus sage de faire plusieurs releases. J'ai l'impression que nous voulons faire passer Django 1.7 et Python 3 un peu trop vite. L'API des membres est déjà un bon morceau. Nous pourrons faire passer Django 1.7 ou Python 3 (ou les 2 sont bien testés), dans la prochaine release.

J'aurais pensé que la version 2 viendrait avec la version 1 stable de l'API, personnellement (donc pas uniquement le module membre) et potentiellement la ZEP 12. Mais c'est sans doute trop long terme x).

Une API stable et complète, ça se compte en mois et pas 2-3.

Alors je vais répéter ma réponse en reformulant : je ne vois pas d'inconvénient au fait de passer l'API, le passage à Python 3 et Django 1.7 (les deux sont liés à mon sens), et la ZEP-04 dans une seule très grosse version (2.0), à condition de prendre notre temps pour la coder et la tester et donc de faire une version intermédiaire (1.6) qui serve à écluser les corrections et améliorations n'appartenant pas à un de ces 3 gros chantiers.

Bon, vous m'avez convaincus : je lance la release v1.6 en l'état.

Hop, la suite c'est par ici.