Je suis nouveau. Et ravi de vous rejoindre.
Je ne suis pas certain d’être au bon endroit (mais je vous promets d’avoir cherché relativement longtemps)
Il était question que Spip 5 ne supporte plus (ou plus totalement) paquet.xml au profit de composer.json ? Mais il était aussi question de garder les deux modes de fonctionnement au moins pendant un temps. J’attire l’attention sur un point que je n’ai vu nul part relatif à la mise à jour par SVP. Il arrive que certains environnements mutualisés soit dépourvus de composer, où que l’usage de celui ci soit restreint (par liste blanche par exemple). La non dépendance à une binaire telle que celle de composer est, de mon point de vue, une fonctionnalité en soit. Du coup, il serait interessant que SVP puisse continuer de fonctionner sur ces environnements, y compris pour des packets complètement composerisés. Qu’en pensez vous ? (redirigez moi, avec toutes mes excuses, vers la bonne discussion si besoin est)
Cela n’a jamais été remis en cause pour SPIP5, SVP fonctionnera comme dans SPIP4.4
composer est un outil de développement, tout comme git. Il n’est pas recommandé de s’en servir pour le déploiement, l’installation ou les mises à jour sur un serveur de PROD.
spip_loader continuera de fonctionner. Et comme dit plus haut, SVP aussi.
J’en déduis que même si le numéro de version sera peut être un jour exclusivement donné par le composer.json (j’avais lu ça sur un vieu post… pourquoi pas…) il ne sera jamais envisager que la mise à jour via SVP ou spip_loader utilise composer ou git, ce qui, en plus d’être impossible sur certains environnements serait effectivement une hérésie en PROD.
D’ailleurs faites vous parfois des mises à jour en prod via SVP et spip_loader? Les yeux fermés? Jamais ? Seulement pour des versions mineurs?
J’avoue l’avoir fait pour de petits projets bénévoles après sauvegarde. Et à part de minuscules détails je n’ai eu de problème avec aucun plugin.
Je me dis que malgrè l’absence d’une grosse couverture de tests unitaires, le côté « unix » de beaucoup de plugins (je fais une chose simple et je la fais bien) est déjà un gage de confiance.
Je reviens vers Spip après plusieurs années et ces récentes innovations me rendent très enthousiaste.
Ce n’est pour sûr pas prévu en SPIP 5.x ; et ce serait difficile à mettre en place avec SVP et notre gestion de plugins actuelle de toutes façons.
Par ailleurs, la majorité des gens ici déploient en PROD soit avec Git (l’outil checkout), soit avec spip_loader, et les plugins via SVP : comme disait James, ce n’est pas idéal / recommandé (d’un point de vue de la sécurité informatique notamment), mais c’est aussi le plus simple actuellement, faute d’avoir des outils de déploiement dédiés faciles à mettre en place et des tutos associés (CI sur gitlab/github, Deployer PHP, Ansible…)
Je suis curieux de savoir de quelles innovations tu parles ?
Oui, les yeux fermés pour les versions versions mineures. Pour les versions majeures, j’ouvre les yeux quand même : sites simples en prod avec spip_loader (après 1 ou 2 tests en local), sites plus délicats en local systématiquement avant la prod.
La prise en charge de l’autoload et composer entre autre. J’irais jusqu’à dire : l’arrivé de l’objet tout court!
En vrai la dernière fois que j’ai utiliser Spip c’était en 2010.
Du coup de mon point de vue ça a beaucoup bougé.
