La prochaine version, 2.11, de Dotclear est prévue pour mi-février, la suivante, la 2.12, pour mi-août. J’enchaîne ainsi les versions majeures tous les 6 mois, depuis 2 ans.
Seulement voilà, dans « versions majeures » il y a l’adjectif majeur. Compte-tenu de l’état des troupes, est-il raisonnable de vouloir tenir ce rythme, surtout en incluant à chaque version des fonctionnalités ou des améliorations qui justifient à elles seules l’attribut d’un numéro de version majeure (sachant que le préfixe 2. des versions est historique et ne devrait, a priori, jamais être remis en question, sauf à ré-écrire complètement le moteur, ce qui n’est pas à l’ordre du jour, vous vous en doutez bien).
Certes il y a encore plein de choses à explorer, éventuellement à coder, mais on parle d’un projet plutôt mature, qui ne devrait, normalement, pas connaître de révolution dans les versions à venir. De là à dire que du coup plus rien ne justifie d’attribuer l’adjectif « majeur », il n’y a qu’un très léger pas…
Le pendant à ce rythme semestriel est d’opter pour une livraison de version majeure qu’à partir du moment où son contenu le justifie, mais comme je le disais plus haut, a-t-on encore de quoi ? Une API REST complète, l’intégration du moteur Twig en parallèle à celui de Clearbricks pour les templates, une refonte de l’administration — qui d’ailleurs pourrait s’appuyer à la fois sur l’API et sur Twig, on peut rêver —, … Voilà de quoi « majorer » des versions, sauf qu’on a pas les troupes derrière, donc non.
Personnellement j’estime que tant pis si le contenu n’est pas à la hauteur de ce qu’on peut espérer de majeur dans une version, je préfère continuer à publier tous les 6 mois, voire pourquoi pas plus fréquemment, simplement pour maintenir un peu de vie dans Dotclear, pour montrer que ça bouge encore, même si on utilise des technos vieillissantes qui feraient hurler d’horreur tous ceux qui ne jurent que par le dernier langage/framework/environnement à la mode cette semaine.
Voilà mon avis assez arrêté sur cette question et ça m’intéresserait pas mal d’avoir le votre, ici ou chez vous, peu importe…
PS : Accessoirement les codenames des prochaines versions ne sont pas encore figés, donc si vous avez des suggestions ;-)
1 De olivier -
Pourquoi ne pas incrémenter juste la version « micro », si il n’y a pas de grands changements (comparée à une version dite majeure).
Tu le dis très bien, que quelques fois ce n’est pas forcément justifié. Je doute que tous les utilisateurs t’en veuilles.
2 De Philippe -
Et pourquoi ne pas publier chaque version mineure, histoire de pouvoir utiliser les nouveautés et améliorations dès qu’elles sont fraîches ? Parce que là, 6 mois, c’est un poil long :P
3 De Biou -
J’aime bien ton approche. De toute façon le majeur ou mineur est relatif au contexte du projet.
Et je dis ça aussi juste pour contredir les collègues ;)
4 De Luc -
Tu peux les appeler comme tu veux.
Après je crois que les utilisateurs de DC dont moi, n’attendent pas une sortie à heure pile avec des modifications majeures comme le passage de DC1 vers DC2.
Ça doit sortir quand ça doit sortir. Quand c’est prêt !
5 De Sylvain -
Max tous les 6 mois en maintenant la règle du quand c’est prêt me convient très bien. Cela permet de garder le rythme ; après majeur/mineur à assez peu d’importance. C’est toujours une joie de voir la proposition de mise à jour :)
6 De Cunégonde -
Onze et douze comme nom ça devrait le faire, non ? Pour le reste fait comme tu veux/peux. Je suis d’une piêtre aide.
7 De JcDenis -
1) Pour moi et dans le cas de Dotclear, majeur/mineur importe peu, majeur voudrait dire incorporation d’un nouveau truc assez gros et/ou non compatibilité avec l’ancien, 2 choses que Dotclear ne connait pas :p
2) Un rythme de mise en prod tous les 6 mois peu paraitre long, mais si rien ne justifie la sortie d’une nouvelle version pourquoi le faire ! Je pense même qu’il ne faut pas en sortir tous les deux jours, rien n’est plus pénible (même si ce n’est que deux cliques) que de mettre à jour un logiciel à chaque lancement de celui-ci…
3) Dotclear a un vieux moulin ? Et alors, il marche super bien, changer pour changer n’a que peu d’intérêt pour moi, tant que ça roule.
8 De Franck -
olivier un changement de version côté micro/mineure — comme le .4 de 2.10.4 — est en général réservé aux versions de correction (failles de sécu le plus souvent mais pas que).
Philippe, sortir des versions plus souvent, pourquoi pas, mais c’est pas anodin question préparation, et puis ça modifierait probablement notre façon de gérer les versions sur le dépôt mercurial, ce qui n’est pas non plus sans conséquences.
9 De Pep -
Et pourquoi ne pas faire comme de plus en plus le font désormais : opter pour une numérotation “annuelle” ?
Genre 2016.4.1, avec :
Je trouve cela plutôt souple (en tout cas, je m’y suis fait). :-)
Et ça me semblerait bien coller au mode de livraison que tu envisages.
10 De Franck -
« … de plus en plus … », à part les realeases Ubuntu, j’vois pas, du coup j’veux bien des exemples :-)
11 De Pep -
SaltStack, Kali Linux, la lignée des produits JetBrains…
12 De Franck -
Ah effectivement (d’ailleurs faut que je mette à jour mon petit PC de test et sa (relativement) vieille Kali) :-)
13 De Pep -
Et même Adobe avec les composants de la suite CC, récemment.
14 De Franck -
Ah tiens, puisque tu parles d’Adobe et de sa sale manie de tout passer en abonnement, on va faire pareil pour Dotclear \o/
Question de mode, hein ? :-)
15 De Pep -
Houla ! Méfions-nous de la mode !
C’est un coup à tout chambouler le modèle économique de Dotclear !
Un audit financier sera nécessaire avant de se décider, histoire de savoir quels seront les impacts d’un tel changement.
Si nous pouvions, au moins dans un premier temps, nous contenter d’appliquer le mode “YOLO!” au seul processus des releases, ça me semblerait beaucoup, beaucoup plus sage.
16 De Franck -
YOLO ? PTDR !