En logique semver, il y a plus de cassage de comportement entre la 3.2 et la 3.3 qu'entre la 2.1 et la 3.0. En effet, même si la 3.0 permettait d'aller plus loins dans SPIP, de mêmoire le code historique restait fonctionnel.
Là on à qui casse:
- la pagination
- les modèles de doc
- potentiellement de renommage de classe dans le privé
Du coup une numérotation 4.0 plutot que 3.3 cela pourrait valoir la peine, surtout qu'en terme fonctionnel on a pas mal de chose (que ce soit niveau compilo, css, etc).
- le changement de version de PHP minimale est aussi une grosse rupture, alors que le passage d’une version 3.2 à une version 3.3 devrait pouvoir se faire partout où la version 3.2 fonctionne;
- les belles évolutions graphiques, nettement perceptibles entre la 3.2 et la 3.3, rendent aussi légitime une changement de version majeur.
Plusieurs remarques. Il ne me semble pas forcément pertinent pour la distribution SPIP / SPIP-core (je ne parle pas des plugins ou librairies) de suivre semver à tout prix. Il me semble qu'on est plus dans une notion un peu de paradigme de programmation (le X) : le 3 indiquant le passage aux paquet.xml pour les plugins.
Si l'on considère que dès que l'on casse potentiellement quelque chose dans les squelettes on se met à augmenter X plutôt que Y, on serait déjà très haut, quasiment à chaque grande release. Non ?
Qui plus est, il y a des plugins de retro-compatibilité sur les changements apportés (fullcalendar, modèles documents...), et il ne semble pas y avoir de choses particulièrement bloquantes.
Donc, là comme ça je dirais moyen bof.
Mais.
Effectivement indépendamment des trucs qui cassent ou pas, la version à venir a son lot de sympathies, et même visuellement il va y avoir une rupture nette dans l'espace privé.
Par ailleurs, si l'on va effectivement vers un changement du rythme des versions SPIP en suivant l'activité de celle de PHP (et en maintenant quelques temps une 3.2 LTS), c'est un autre argument en faveur d'un changement de paradigme, et du coup d'une version 4.0
J'aurais préféré ce 4 pour du Composer. mais si c'est 5 ou 6 ça ira aussi
Plusieurs remarques. Il ne me semble pas forcément pertinent pour la distribution SPIP / SPIP-core (je ne parle pas des plugins ou librairies) de suivre semver à tout prix.
je trouverais bien d'être cohérent, mais ca se discute
Qui plus est, il y a des plugins de retro-compatibilité sur les changements apportés (fullcalendar, modèles documents...), et il ne semble pas y avoir de choses particulièrement bloquantes.
amah les plugins de retrocompat n'étant pas du code, bah ne peuvent pas compter
Je ne sais pas si on doit suivre la logique semver pour la release qui arrive, ou bien (plutôt) pour les suivantes (?)
Il y a effectivement des ruptures, des choses qui cassent comme tu le dis (et je mettrais les plugins de compat hors discussion, ce sont juste des pansements), et de belles évolutions graphiques comme dit ARNO (largeur de l'espace privé, et tout ce qui est en discussion sur les formulaires et autres).
En terme de "communication", je serai donc totalement pour une 4.0
Au moins ce serait clair pour tout le monde.
Alors justement à propos de repousser ou pas : si on dit que parce qu'il y a pas mal de modifs *dont notamment l'admin* qui change un peu de tête (surtout graphiquement, pas vraiment ergonomiquement), et bien comme tu le dis très justement dans un ticket : "actuellement en 3.3 l'admin fait un peu sapin de noël" !
=> est-ce qu'on a vraiment envie de sortir une version majeure où les gens se disent "euh ça fait sapin de noël" ?
Pour le coup en terme de communication je ne trouve pas ça super justement…
Moi perso ça ne me va pas (je précise plus explicite : ça ne me va pas si c'est avec un numéro majeur).
Et du coup :
- soit il faudrait attendre de se mettre d'accord sur l'iconographie mais justement ça peut prendre trop longtemps, alors qu'on veut sortir cette version dans 2-3 semaines
- soit il ne faut pas que ce soit une majeure
Annexement pour moi une 4.0 serait :
- soit pour Composer
- soit pour une réelle refonte ergo de l'admin, pas juste les styles graphiques améliorés
Annexement pour moi une 4.0 serait :
- soit pour Composer
- soit pour une réelle refonte ergo de l'admin, pas juste les styles graphiques améliorés
Je suis d'accord, je ne voulais pas jouer le grognon de service à propos de cette 4.0, mais j'ai du le laisser transparaître dans ma formulation
Je pense aussi ça la 3.3 actuelle ne mérite pas un saut de X, cf ce que disait marcimat au sujet de notre "politique" de numérotation jusqu'à maintenant.
Et surtout, j'ai bien peur que ce grand saut de numéro nous mette dans un posture où on osera pas faire le grand saut de la release, ce qui nous laissera tout le temps de continuer à coller des chantiers plus ou moins gros dans le master, et donc au final repousser la release.
En fait, on s'est foiré sur un point, suite au sprint et à l'idée de potentiellement releaser en avril/mai, on aurait du créer tout de suite une branche 3.3 pour justement préparer la release sans freiner les expérimentations dans master. Mais bon, on fera mieux dans notre prochain cycle
Ça patche dans le lard de partout au niveau design / ux, et ça donne une grande impression de pas fini.
Entre les icônes sapin de noël, les formulaires et autres bidules à droite à gauche sans cohérence, ça va demander du boulot pour fignoler tout ça vraiment proprement.
Personne n'a dit qu'on sortait une version finale de toutes façons. L'idée c'était quand même plus une alpha ou beta…
Quant au sapin de noel… C'est très relatif : les icones sont bien plus nettes qu'avant en SVG… et il y a eu quelques améliorations ça et là ; et tout va dans le bon sens je crois. Vu les icones d'avant, ça semble mieux même en l'état très imparfait. Alors certes c'est pas parfait mais bon.
Sur les boutons principalement, et formulaires, etc, l'idée me semble t'il est justement d'apporter de la cohérence, et là encore bah oui, y a des corrections à droites à gauches à apporter… et ça prend du temps de se mettre d'accord, mais là encore je trouve que ça prend une bonne tournure avec les variables CSS entre autres. Et il va falloir un peu de temps pour les utiliser partout et combler les manques.
Vous aviez réussi à me convaincre pour le nommage 4.0 … on ne sortira jamais de version parfaite de toutes façons. On ne sera jamais entièrement satisfait. Je suis quasiment sûr qu'on pourrait néanmoins être heureux de l'appeler 4.0 et d'arriver avant à corriger les points les plus dérangeant.
Sur les icônes : les couleurs sont super flashy, ce n'était pas le cas avant, elles étaient beaucoup moins saturées.
Et il n'y a pas de cohérence de style graphique, de contour ou d'à plats, d'épaisseur de trait, etc...
Spip a toujours travaillé sur la durée, avec du tout en allant en fonction des disponibilitées de chacun,
alors en tant qu’utilisateur de spip je sais que la version qui sort et ceux quelque soit la version
est déjà dépassé, car les dev sont déjà sur l’amélioration de la version suivante.
Alors le parfait n’existe pas,et si la version que j’utilise ne me convient pas, je dis rien car je sais que derrière il y aura encore un truc mieux mais pas forcement aussi aboutie que le souhait des devs
de toute manière l’urgent est fait, l’impossible est en cours, pour le reste, prévoir un délai.
ça fais trop longtemps qu’on entend parler de la 3.3, je l’attendais le 1 Avril, j’ose espérer le 1° Mai , le jour de la fête du travail des devs de spip
Non entre une beta et une release finale il y a pas de différence fonctionnelle (il devrait pas y en avoir).
Et donc je pense que le mieux c’est :
• sortir une beta au 1er mai et la numéroter 4.0 au vu des ruptures de compat et du saut de version PHP requis
• créer la branche 4.0 partout (core et plugins dist) pour ne plus y envoyer de nouvelles features mais uniquement du bugfix
dans ma position d'utilisateur j'ai toujours été très content du rythme prudent des mises à jour de SPIP. J'ai une une poignée de sites assez divers à mettre à jour "manuellement" à chaque sortie d'une nouvelle version.
Alors quand il n'y a pas de problème de sécurité à resoudre immédiatement je suis content quand il faut attendre un peu plus longtemps l'arrivée du SPIP suivant
Pour ce qui est la sortie d'une nouvelle version majeure 4 je pense qu'elle s'impose lors de l'introduction obligatoire de PHP 7.
Il serait pourtant dommage si cette nouvelle version ne comportait pas d'autres avancées essentielles attendues depuis longtemps. Je pense par exemple à la possibilité de créer des distributions individuelles (par ex. spip 4 + tel squelette + tel design + telles fonctionnalités + telle reconfiguration par mes_options)
Peut-être le 1er juillet serait une bonne date pour sortir la prochaine version majeure. Elle marque le vingtième anniversaire de la publication officielle de SPIP 1
Je profite de l'occasion pour vous remercier pour votre travail si soigneux tout au long de ces années. Bonne continuation !
Non entre une beta et une release finale il y a pas de différence fonctionnelle (il devrait pas y en avoir).
Et donc je pense que le mieux c’est :
* sortir une beta au 1er mai et la numéroter 4.0 au vu des ruptures de
compat et du saut de version PHP requis
* créer la branche 4.0 partout (core et plugins dist) pour ne plus y
envoyer de nouvelles features mais uniquement du bugfix
Et ne pas oublier de faire un grep sur la zone pour tous les paquet.xml ayant déjà déclaré la compatibilité SPIP 3.3 …
pour les passer en 4.0
Moi non plus je veux pas jouer les grognons de service mais :
• cette nouvelle version requiert un saut de PHP et laisse tomber PHP 5x, ce qui n’est pas mineur
• introduit un certain nombre de nouvelles syntaxes sur les balises et les boucles (boucles anonymes, en-tête et pieds de boucles, boucles dans les balises) qui font que les squelettes de cette version ne seront pas utilisables sur une plus ancienne version
• introduit des ruptures de compatibilité sur le rendu des sites : modeles document, pagination
• enlève jQuery UI
• et accessoirement introduit le support complet de SVG y compris dans les filtres images, ce qui n’est pas rien
On ne veut pas que les utilisateurs upgradent juste leur site à la légère et découvrent que plus rien ne marche parce qu’ils ont un vieux PHP<7.3 ou que tout leur site est visuellement cassé (et le travail pour remettre en ordre n’est pas forcément léger selon les cas)
Donc la question n’est pas de savoir ce qu’on aurait voulu mettre dans une 4.0, mais de savoir si les ruptures de compatibilité et les nouvelles fonctionnalités sont suffisantes pour justifier un saut de numérotation et il me semble que oui.
Je ne suis pas du tout programmeur. Au fil des courriels sur le sujet, je m’attends à ce qu’il y ait du boulot à accomplir en changeant de version … ce qui n’est généralement pas le cas lorsque je fais les mises à jour de versions SPIP.
J’aimerais en être prévenu si la mise à jour rend les sites dysfonctionnels. Idéalement, avoir également en mains une feuille de route qui pourra me permettre de réagir et me remettre en contrôle !
