Un jour, dans la rue, je suis passé le long d’un mur où il était écrit en lettres rouges et dégoulinantes, c’était encore frais : « Ni wordpress, ni drupal ! »
Personnellement, si je « fais comme », c’est plutôt comme Symfony. Un autre dieu, un autre maître. Je peux bien le confesser.
Est-ce autant un « réflexe d’imitation » que cela ? Est-ce qu’on s’adonne à un rituel magique sans vraiment comprendre ce qu’on fait ? Juste parce qu’un gourou nous aurait subjugué ?
Qui « sait » ce qui convient à SPIP ? Serions-nous en phase si nous en discutions ? Est-ce que « utilisateur(ice)s » ne serait pas un mot un peu fourre-tout derrière lequel il est facile de se cacher ?
J’ai pu observer des échanges et des messages dans la catégorie général de ce forum, et parfois aussi sur irc, dans lesquelles des personnes semblaient trouver rassurant que nous usions d’une terminologie assez classique pour parler de ce que nous publions. Le « semantic versionning » est plutôt répandu de nos jours. Il me semble que c’est même assez commun. Les « utilisateur(ice)s » ne sont plus des béotiens éterrnels, du moins, j’aime à le croire.
Alors, oui, par contre, on peut simplifier la communication, c’est un peu le but de ce topic que de trouver le bon rythme et effectivement, partant d’une pratique remontant, dans SPIP à au moins 2011, je suis d’accord sur un autre de tes points : « Qu’est-ce qu’on attend quand on publie une pré-release et qu’est-ce qu’on attend des testeurices ? » … Sans doute qu’un coup de main des @fonctionnel, de la @documentation, ne serait pas de refus
comme @bricebou et @placido, je serais pour simplifier pour les dev SPIP et les utilisateur·ices (qui administrent des sites) : une bêta directement à la place de l’alpha (2 mois avant pour laisser le temps de tester ?) avec code freeze + d’autres bêtas si besoin.
J’ai l’impression, mais peut-être me trompe-je, qu’il n’y a pas suffisamment de temps et/ou de monde pour les alphas, donc autant se concentrer sur des bêtas.
Pour pouvoir tester facilement les dev, alpha, beta, il faudrait déjà que spip_loader.php propose la 4.4dev, alpha, beta
Or, actuellement, il n’y a que Dev qui doit signifier 5.0dev ? (en fait, on ne sait pas à regarder le formulaire)
⇒ Est-ce que spip_loader pourrait proposer 4.4 dev et 5.0 dev (et plus généralement, toutes les branches pertinentes dans le futur) ?
Ceci afin de pouvoir proposer de tester plus facilement.
Dans mes cartons, j’ai un bout de code qui ajoute une notion de config supplémentaire dans le loader pour choisir le « niveau de stabilité » de l’installation à faire : « dev », « test », « stable » … mais il y a des pré-requis à cela hors du code du loader : l’API spip_loader doit être améliorée, les zips des branches doit être mis en place, en plus des zips des tags et de l’unique branche « master » … on commence à parler de CI, d’utiiser les releases gitlab en lieu et place du « débardeur », etc…
Donc, ça viendra, un jour … entre la maintenance, la sécu et ça, au nombre de personnes que nous sommes à « faire », ce n’est qu’une question de temps et de priorité.
EDIT: et le périmètre de cette catégorie, ce sont les dépôts spip/* du serveur git. C’est pas déplacé de parler du loader, mais son évolution concerne à la fois moins de monde (@marcimat et moi-même pour sa maintenance, en caricaturant), et « plus de monde », vu qu’il est développé dans un groupe git « communautaire »
je pense surtout qu’il ne devrait pas proposer de version dev dans la liste par défaut.
Une version dev… c’est une version dev… spip_loader est pas vraiment fait pour installer cela il me semble.
Qu’il y ait une « nightly » de la dernière branche 4.x publiée, pourquoi pas éventuellement ; pour le reste il me semble que d’autres outils sont plus adaptés pour tester des branches de dev.
Donc, 2 pré-releases avant fin janvier, code-freeze.
Pour la période 2 tendances se dégagent :
2 mois approximativement (ou légèrement moins) avant la release pour la première « beta » : avis majoritaire, notament chez les mainteneurs actifs.
moins de 2 mois ou rien du tout pour une petite minorité.
Je propose qu’on se donne RDV fin novembre/début décembre pour préparer les « premières beta » de 4.4 et 5.0… ça nous permettra de trouver un juste milieu.
Si les choses se poursuivent comme en ce moment, début novembre, on sort une 4.3.4, début décembre, une 4.3.5 … je ne serai pas contre un petit décalage de quelques jours entre les releases mensuelles et « des beta », ne serait-ce que pour maîtriser un peu le flux d’infos que ça va générer en terme d’annonces et tout ça. Sans que ça tombe au tout début des fêtes de fin d’années non plus.
Et je garde en tête les questions que @nicod nous pose.
Eventuellement si tcharlss a le temps, sa refacto des liens de traductions
Enfin, bien que cela ne preesse passe, il y a cette PR qui est bloqué uniquement sur la question du texte de l’item de langue ^^
Il y enfin le sujet sur les auteur·trices et les termes, qui pareil, semble bloqués au niveau du voc. Donc soit on tranche rapidement, soit bah tant pis ca attendra.
