Je ferais bien la modif mais ça risque de casser l'affichage sur les sites en prod si les styles des h2 ont été modifiés. Comment on s'y prend dans ce cas, ça ne vaut quand même pas un changement de version majeur, si ?
Bonjour Jean-Marie,
Il y a mon site de balade en vélo qui n'est pas déclaré sur spip.net et qui je suppose n'est pas compté dans les 16 sites velovacances.jack31.org
J'ai pas mal de surcharges mais ça ne doit pas être compliqué de remplacer les pages concernées par de nouvelles surcharges et là perso j'ai le temps de le faire. L'an dernier pendant ma balade je prenais bien garde de ne pas mettre à jour le squelette. Je l'ai fait à mon retour en août sans tout vérifier. Ca va être le bon moment de le faire avant de repartir !
Je ne sais pas si changer de version majeure serait suffisant pour empêcher une mise à jour intempestive qui casserait : avec svp on est simplement prévenu de la version *si* on survole le logo de maj... En général je coche toutes les maj et je lance et version majeure ou pas ça s'upgrade.
Mais s'il y a une amélioration de structure je crois qu'il faut la faire (et là maintenant je peux suivre chez moi)
Je ferais bien la modif mais ça risque de casser l'affichage sur les sites en prod si les styles des h2 ont été modifiés. Comment on s'y prend dans ce cas, ça ne vaut quand même pas un changement de version majeur, si ?
J'ai un chantier en cours basé sur ce squelette. La modification ne cassera pas que les surcharges css, elle forcera aussi les gens à reprendre les squelettes qu'ils auraient surchargé ou ajouté (pages persos, etc), donc amha il faut faire péter un saut de version majeur.
va pour la version majeur.
Du coup, des questions me viennent pour l'orga Git :
Sur SVN, on aurait fait une branche pour la V1 et passé le trunk en V2. Maintenant qu'il y a git, on fait une branche V1 et on passe le master en V2 ?
Si oui, comment se fait le lien avec SVN (création de la branche sur SVN) ?
Et, questions FAQ subsidiaire : comment on fait une branche avec git ?
Bon, peut être que cette modif sur ce plugin n'est pas le bon exemple (c'est une "mini" rupture de compat), mais j'ai la même question pour hyperspace qui a été refondu intégralement et dont les versions SPIP ne sont pas les mêmes. Donc il serait intéressant de garder l'ancienne version pour les vieux SPIP.
Alors : git branch -d dev
…va supprimer la branche localement, d’où l’erreur si elle n’existe pas chez toi.
Ensuite : git branch
…tout court pour lister toutes les branches que tu as localement, avec un petit signe (astérisque de mémoire) devant la branche courante.
Enfin, quelque chose comme : git push -d dev
…pour supprimer la branche distante si tu es autorisé(e) à le faire (par exemple si ce n’est pas une branche protégée ni la seule restante et que t’as le privilège de suppression de branche, ce qui est le cas quand tu es propriétaire ou mainteneureuse)
