Peu importe qu’il s’agisse d’une bibliothèque ou d’une application plus grande. Un schéma de versionnement sémantique fonctionne parfaitement bien pour une grande application. Il peut même être utilisé pour une collection d’applications regroupées dans une plateforme, mais ici, cela devient assez difficile à gérer.
La question principale est de savoir si vous optez pour la voie de la dépréciation prise en charge dans une version et seulement la suppression dans la prochaine version majeure. Avoir une fonctionnalité dépréciée mais prise en charge peut demander beaucoup d’efforts. Lorsque vous allez apporter des modifications à votre modèle de données persistant, la dépréciation peut souvent devenir impossible. Si cela se produit, vous ne pouvez même pas faire une version mineure avec une fonctionnalité dépréciée, et vous passez instantanément à une nouvelle version majeure. C’est là que les grandes applications ont généralement des problèmes. Vous passez de 3.0.0 à 3.0.1 à 4.0.0 car vous ne pouvez pas assurer la rétrocompatibilité. Si vous avez souvent des changements majeurs, s’en tenir à semver ajoute peu de valeur.
Cela dit. Je préfère beaucoup cette construction car elle communique plus clairement aux développeurs qu’il y aura des changements majeurs. Le schéma AAAA.N ne me dit rien en tant que développeur, ni en tant qu’administrateur.
La question est donc, que voulez-vous communiquer avec la version ? Si vous voulez faire 6 versions de fonctionnalités (qui peuvent ou non être majeures), et que toutes les 6 versions seront plus longtemps prises en charge avec des correctifs ; et que vous ne voulez pas versionner les versions de correctifs. Alors X.Y est un schéma approprié où Y=0 est celui qui est plus longtemps pris en charge. X serait juste un nombre. Le problème est que lorsque X est l’année, Y est rapidement associé à un mois. Donc les nouvelles versions plus longtemps prises en charge sortiront en janvier ? Je dois toujours chercher quelle version d’Ubuntu est une LTS, ce qui m’agace.
Alors, que se passe-t-il si Discourse continue simplement avec la version majeure actuelle. La prochaine version plus longtemps prise en charge s’appelle 4.0 ; et ensuite nous obtenons 4.1 à 4.5 comme versions de fonctionnalités ; suivies de 5.0 qui est la plus récente version plus longtemps prise en charge.
Alors vous n’aurez pas non plus ce moment gênant où une version est retardée à cause d’un problème majeur.
Vous pourriez éventuellement ajouter un numéro de « correctif » si vous prévoyez de publier explicitement des correctifs (au lieu d’avoir des correctifs continus). « Mais alors vous avez x.y.z qui est semver ». Eh bien non, cela ressemble à semver, mais ce n’est pas le cas. Chaque nouvelle version « mineure » peut être majeure. Je suggère donc de s’en tenir au schéma de version X.Y avec Y=0 → LTS.
Indépendamment de la chaîne de version. J’aime bien le nouveau plan de publication.