CalVer is a versioning convention based on your project's release calendar, instead of arbitrary numbers.
Parler de choix de nombre « arbitraire » pour la suite naturelle des entiers de même nature pour indiquer des jalons successifs, faut être gonflé... Si c’est dans le sens de « choisir arbitrairement si telle ou telle version relève de la révision, du mineur ou du majeur » ça n’a pas plus de pertinence. On définit généralement des règles univoques au niveau compatibilité et fonctionnalité, comme je l’expliquais.
Parce que soit tu numérotes bêtement par YYYY.MM selon la date à laquelle tu sors la version, sans autre considération, et je suis d’accord que ce n’est absolument pas arbitraire dans ce cas mais tu perds alors toute indication de maturité/compatibilité du logiciel. Soit tu acceptes de sortir une version 2015.XX en 2016 ou en 2017, parce qu’il n’y a pas de changement majeur, comme un des exemples du lien que tu donnes (Teradata), mais c’est alors l’indication de chronologie qui perd toute véracité.
Alors j’ai bien compris qu’il s’agit d’associer chronologique et sémantique, mais comme très bien dit ici :
The non-deprecated parts of Twisted are backwards-compatible between each successive version, and breaking changes are done on a time basis, where one year must pass and two releases issued between the release deprecating the functionality and the removal of the functionality.
Ça demande donc de soumettre le développement à des impératifs temporels, vraiment arbitraires pour le coup ! Et prétendre le faire sans rien sacrifier à d’autres impératifs, tels que ceux de répondre aux besoins exprimés par les utilisateurs, ou la qualité de travail fourni par les développeurs, ça me paraît assez optimiste ou prétentieux. Ou alors, à faire comme Teradata, et dans ce cas, avoir comme majeures : 2022,2023,2025 au lieu de 1,2,3 te permet juste de savoir qu’il y a eu deux ans (environ) entre les deux dernières versions majeures au lieu d’un seul (environ) entre les deux versions majeures précédentes. C’est une information vraiment intéressante !
Et oui, « environ », parce que si pour une raison quelconque tu dois sortir une, par exemple, 12e version mineure de ta majeure 2015, dont la première mineure était la 2015.01 (sortie en janvier 2015 donc), bah tu te retrouveras avec une 2015.13, etc... Ou alors quoi ? Tu sors ta majeure 2016 au forcing ? Ou bien tu numérotes ta 2015.13 en 2016.03 (par exemple, si on est en mars 2016 à ce moment) sans changement justifiant une incrémentation du numéro majeur, en abandonnant alors toute cohérence sémantique ?
Donc pour résumer, soit tu imposes un calendrier relativement strict au développement en utilisant CalVer, soit non, et dans ce cas ce versioning n’apporte strictement rien. À moins que, par chance, ton développement se cale magiquement sur le calendrier, ou bien, que tu acceptes d’ôter toute signification sémantique s’il advient que ça ne puisse pas être le cas.
Ça a limite tendance à conforter ce que je disais à propos d’une mode... Parce que des projets qui adoptent CalVer car, consciemment ou non, ils veulent (se) donner l’image d’un projet « carré », avec un calendrier précis, donc une roadmap parfaitement définie et les moyens de s’y tenir, je doute qu’il n’y en ait pas quelques uns quand même !
[^] # Re: Déjà annoncé
Posté par Marotte ⛧ . En réponse au lien LibreOffice 24.2, prochain successeur de LibreOffice 7.6, est disponible en version beta. Évalué à 5. Dernière modification le 18 décembre 2023 à 20:15.
Je ne suis qu’à moitié convaincu.
Parler de choix de nombre « arbitraire » pour la suite naturelle des entiers de même nature pour indiquer des jalons successifs, faut être gonflé... Si c’est dans le sens de « choisir arbitrairement si telle ou telle version relève de la révision, du mineur ou du majeur » ça n’a pas plus de pertinence. On définit généralement des règles univoques au niveau compatibilité et fonctionnalité, comme je l’expliquais.
Parce que soit tu numérotes bêtement par YYYY.MM selon la date à laquelle tu sors la version, sans autre considération, et je suis d’accord que ce n’est absolument pas arbitraire dans ce cas mais tu perds alors toute indication de maturité/compatibilité du logiciel. Soit tu acceptes de sortir une version 2015.XX en 2016 ou en 2017, parce qu’il n’y a pas de changement majeur, comme un des exemples du lien que tu donnes (Teradata), mais c’est alors l’indication de chronologie qui perd toute véracité.
Alors j’ai bien compris qu’il s’agit d’associer chronologique et sémantique, mais comme très bien dit ici :
Ça demande donc de soumettre le développement à des impératifs temporels, vraiment arbitraires pour le coup ! Et prétendre le faire sans rien sacrifier à d’autres impératifs, tels que ceux de répondre aux besoins exprimés par les utilisateurs, ou la qualité de travail fourni par les développeurs, ça me paraît assez optimiste ou prétentieux. Ou alors, à faire comme Teradata, et dans ce cas, avoir comme majeures : 2022,2023,2025 au lieu de 1,2,3 te permet juste de savoir qu’il y a eu deux ans (environ) entre les deux dernières versions majeures au lieu d’un seul (environ) entre les deux versions majeures précédentes. C’est une information vraiment intéressante !
Et oui, « environ », parce que si pour une raison quelconque tu dois sortir une, par exemple, 12e version mineure de ta majeure 2015, dont la première mineure était la 2015.01 (sortie en janvier 2015 donc), bah tu te retrouveras avec une 2015.13, etc... Ou alors quoi ? Tu sors ta majeure 2016 au forcing ? Ou bien tu numérotes ta 2015.13 en 2016.03 (par exemple, si on est en mars 2016 à ce moment) sans changement justifiant une incrémentation du numéro majeur, en abandonnant alors toute cohérence sémantique ?
Donc pour résumer, soit tu imposes un calendrier relativement strict au développement en utilisant CalVer, soit non, et dans ce cas ce versioning n’apporte strictement rien. À moins que, par chance, ton développement se cale magiquement sur le calendrier, ou bien, que tu acceptes d’ôter toute signification sémantique s’il advient que ça ne puisse pas être le cas.
Ça a limite tendance à conforter ce que je disais à propos d’une mode... Parce que des projets qui adoptent CalVer car, consciemment ou non, ils veulent (se) donner l’image d’un projet « carré », avec un calendrier précis, donc une roadmap parfaitement définie et les moyens de s’y tenir, je doute qu’il n’y en ait pas quelques uns quand même !