Zeste de Savoir passe en version 1.7

Hé oui, 2 news ZdS de suite… normalement on évite, mais l'actualité était trop trépidante !

Merci à vous tous pour ces comptes rendus, c'est vraiment cool de voir tout ce qui a été fait dans les différentes version !

C'est vrai qu'on avait dit dans le sujet dédié d'éviter d'avoir trop de choses à la fois dans une même release (la 2.0), mais je trouve dommage que la version 2.0 soit liée à un changement qui

Pour vous les visiteurs, rien de visuel ne changera

La nouvelle page d'accueil, ça aurait été cool pour marquer le coup de la 2.0.

Bon après c'est qu'un numéro de version, on va pas en faire tout un plat

Merci pour les infos !

@Javier, c'est l'éternel débat entre numéros de versions pour le public et numéros de versions pour la technique. On a pris le parti d'avoir un numéro de version technique (à commencer à cause du système de releases : "on release quand on a assez pour faire une release"), donc le passage à Python 3 justifie bien plus une v2 que la page d'accueil (la ZEP-12 serait un bon candidat aussi, d'ailleurs).

(la ZEP-12 serait un bon candidat aussi, d'ailleurs).

Cool, on fera une "version 3" 2 mois apres la v2

Oui, on était nombreux à avoir réclamé que l'aboutissement de la ZEP-04 marque le passage à la v2.

EDIT : mon message venait juste après celui de Javier.

On peut peut-être faire en sorte de mettre la ZEP 4 et Python 3 dans la même version, non ? Comme ça on aurait une version 2 technique et pour le public !

Oui enfin ça suppose qu'on arrive a faire coïncider les deux., c'est pas évident ! Pour la ZEP-4 je ne sais pas, pour le passage à Python3, une fois pret, chaque attente avant le merge va provoquer des conflit pénible à régler.

Très sincèrement, je n'arrive pas à comprendre ce qui vous dérange tant dans le concept de "numéro de version technique", pour deux raisons :

1. C'est une pratique courante. Sur le web ça ne se voit pas parce que les utilisateurs ne voient généralement pas les numéros de version ; et côté logiciels c'est de plus en plus fréquent (Chrome, Firefox, etc.)
2. Le numéro de version de la plate-forme technique de Zeste de Savoir n'a jamais été lié aux fonctionnalités utilisateur : le site est sorti sur une version bêta de la plate-forme, et la v1.0 ne correspondait à peu près qu'à l'arrivée d'un code stable. Dès lors, lier le numéro de versions aux fonctionnalités n'a plus vraiment de sens.

Maintenant si ça vous perturbe autant, on peut faire plus simple : supprimer le numéro de version de la plate-forme du footer voire arrêter les articles à ce sujet. Mais ce serait dommage, non ?

@Situphen : ce n'est pas comme ça que ça fonctionne. On sort les versions quand elles sont prêtes, avec une énorme contrainte d'hébergement pour le passage à Python 3. Si par coïncidence on a la ZEP4 et Python 3 dans la même version, alors ça marchera comme tu dis – quoique techniquement je préfèrerait éviter un maximum les changement dans une version aussi compliquée à mettre en prod que l'arrivée de Python 3.

Cool, on fera une "version 3" 2 mois apres la v2

Je n'ai aucun problème avec ça, si ça doit arriver. Mais on y est pas encore.

Sinon on bascule a un système de numérotation année.mois.jours lié a la mise en prod et voilà.

Ou alors, on fait une petite entorse à l'habitude de faire des numéros de versions techniques, dans le seul et unique but de faire un coup médiatique. Car, comme le souligne si judicieusement SpaceFox, on fait des articles pour présenter chaque version, et sur les réseaux sociaux et assimilés, « Zeste de Savoir fait peau neuve avec la version 2.0 », ça a autrement plus de poids que « ZdS passe en version 1.7 et se dote d'un morceau d'API ».

Je suis d'accord avec le DTC, sur ce coup. En particulier parce que la plateforme technique du site n'est pas le site.

Mettons-nous 3 secondes à la place d'un développeur qui souhaiterait réutiliser le moteur de ZdS. Pour lui, 2.0, il s'attend à un changement technique majeur, pas à un changement de design. De même que mettre un changement de version de Python (donc casser la rétro-compatibilité) dans un changement de version mineure n'aurait absolument aucun sens.

C'est vrai que ce serait cool si les deux pouvaient coïncider, mais là encore, j'entends parfaitement le raisonnement de SpaceFox : une 2.0 avec Python 3 sera déjà suffisamment difficile à merger/QA-iser/stabiliser pour qu'on ait besoin de prendre des risques en plus.

Au final, le mieux serait que la ZEP-04 soit finie avant le passage à Python 3. Comme ça la v2 sera toute belle dès la mineure 0, mais de là à retarder la migration de la plateforme pour ça…

Comme dis plus haut, pour moi, si la zep-4 est prete avant le passage à python3, je ne vois pas de soucis à la faire attendre. Par contre l'inverse sera un enfer. Une fois pret, le passage à python3 devra être poussé rapidement sinon il faudra rapidement tout recommencer. Ça dépend donc principalement, pour moi, des dev de la zep-4.

BTW, on peut faire une v2 pour le passage à Python 3 et une v3 à l'arrivée de la zep-4 et une v4 à l'arrivée de la zep-12. Comme ça tout le monde est content : les grosses évolutions front et back provoquent un changement de version majeur.

Sinon on bascule a un système de numérotation année.mois.jours lié a la mise en prod et voilà.

J'avais envisagé ça à une époque Mais c'est vrai que c'est encore ce qui correspondrait le mieux à notre mode de fonctionnement.

Ou alors, on fait une petite entorse à l'habitude de faire des numéros de versions techniques, dans le seul et unique but de faire un coup médiatique.

C'est impossible et nohar a très bien expliqué pourquoi.

Je voulais pas déclencher un tel débat honnêtement, désolé.

Et oui j'étais le premier à dire "on n'en met pas trop dans une release sinon c'est la merde à tester / rollbacker".

C'est juste "dommage" pour la raison que Dominus a citée (comm' avec le numéro de version dans les articles sur la vie du site) mais c'est pas possible, point final

Par contre, juste :

Mettons-nous 3 secondes à la place d'un développeur qui souhaiterait réutiliser le moteur de ZdS. Pour lui, 2.0, il s'attend à un changement technique majeur

Faut prendre une décision pour cet argument.

Soit on s'en sert, soit en le laisse de côté. Mais suivant la personne qui l'utilise, la réponse peut être "ouais carrément : bon point !" ou "nan mais soyons honnête, en l'état on s'en fout".

Pour moi, la plateforme étant libre et open-source, et déja forkée/réutilisée, je pense qu'on doit garder cette logique en considération, par principe.

Après, soyons honnêtes, on s'en fout un peu parce que ça ne va pas changer la face du monde ni peser sur les décisions 99% du temps… sauf dans le choix d'un numéro de version, typiquement.

Finalement, je pense que le mieux, ce serait que si la v2 sort en mai, comme Kjé et SpaceFox l'ont évoqué, on aura qu'à la nommer 15.05 et numéroter dorénavant la plate-forme avec le même pattern qu'Ubuntu (année.mois). Ça aura le mérite de résoudre le débat une bonne fois pour toutes, et qu'on s'en foute définitivement de ces considérations.

C'est juste "dommage" pour la raison que Dominus a citée (comm' avec le numéro de version dans les articles sur la vie du site) mais c'est pas possible, point final

Personnellement je ne comprends pas cet argument : s'il y a de la comm' à faire sur les nouvelles fonctionnalités, pour moi on la fait… sur les fonctionnalités, pas sur un numéro de version.

PS : pour les utilisateurs il y a au moins trois choses qu'apportent la ZEP 12 qui peuvent pas mal aider :

• les articles sont désormais aussi puissant que les tuto, i.e nous avons la ZEP03, nous avons les galleries, nous avons le diff
• nous avons la possibilité de créer un nouveau format de tuto qui correspond à ce que les gens ont tendance à appeler les "moyens tutos". Quand on voit que la volonté des auteurs est de créer plutôt un grand nombre de moyens tutos qu'un petit de big tuto, on est quand même dans quelque chose de très visible.
• nous avons la possibilité d'importer depuis tout éditeur offline des tutos et ce même si le tuto n'existe pas encore dans notre bdd, même si votre version offline possède une architecture différente de l'archi online !

Je n'ai pas envie de "sur défendre" la ZEP 12, mais si on fait le produit carthésien de la ZEP 12 par la ZEP 04 on peut largement sortir une version en un gros bloc (quitte même à ne merger que les ZEP et 0 ticket) et appeler ça une version majeure (m'en tappe du numéro) que tout le monde verrait comme une version majeure, aussi bien techniquement que côté utilisateur que côté gens qui ont forké zds.

En soit probablement toutes les zep mériterait ça. L'API par exemple est une fonctionnalité très importante et l'aurai mérité. Mais comme c'est très long a mettre en place, ca va etre fait au fur et a mesure.

Bref je suis de plus en plus convaincu qu'utiliser une numérotation basé sur les dates serait plus pertinent vu notre organisation de dev.

On attend la suite avec impatience, bravo l'équipe dev !

Bravo !

Dans la section L'API des membres, principale nouveauté, dans la liste présente dans cette section, il y a un problème d'accord (mix de passé/présent).

Les numéros de version, c'est un outils pour les développeurs, faire du marketing avec, c'est pourrir l'outil de travail des dev. Maintenant, trouvez une convention logique. Genre xx.yy.zz, quand on fait du bugfix, on incrémente z, quand on ajoute une feature, on incrémente y, et quand on pête la structure ou change de plateforme, on incrémente x. Donc corriger le prix de la cotis', c'est un incrément de z, la ZEPn, c'est un incrément de y, et passer à Python3, c'est un incrément de x. Et puisque les changements de plateforme ne doivent pas affecter l'utilisateur, ils sont potentiellement invisibles.

En y réfléchissant bien, je suis d'accord avec SpaceFox, nohar et Natalya. Le passage à Python 3 est déjà assez compliqué pour y mettre autre chose. Pour ce qui est de la communication, que ce soit v2 ou v1.9/v2.1 les gens s'en fichent. On aura qu'à faire un article "Zeste de Savoir fait peau neuve" ou quelque chose du genre et bien le diffuser. AMHA, ça peut même plus attirer qu'un article "Zeste de Savoir passe en v2" !

Je suis du même avis : laissons les numéros de version aux développeurs, et faisons notre comm' sur du concret, sans s'occuper de ces numéros.

Hello!

Pour ma première impression j'ai vraiment eu du mal à configurer mon compte ( ++ Avatar ) il faudrait améliorer cela .. Sinon jolie site.