Par contre une version mineure n'en est plus une si des nouveautés apparaissent.
Pourquoi? C'est qu'une question de définition. Hormis le fait qu'historiquement beaucoup de projets (dont GIMP) suivaient effectivement cette définition, tu peux tout à fait redéfinir, et dire par exemple qu'une version majeure, c'est quand tu changes quelque chose de... majeur justement (comme le moteur graphique, cas de GIMP 2.10, ou le toolkit graphique, cas de GIMP 3), et une mineure, c'est le reste.
D'ailleurs, si on souhaite se rapprocher du "versionnement sémantique", utilisé massivement, surtout pour des bibliothèques (peu les logiciels finaux) libres, tu peux tout à fait rajouter des fonctionnalités dans une mineure. Ce qui importe, c'est de le faire en restant compatible avec l'existant (tant qu'on ne change pas de version majeure). GIMP fournissant aussi une API (pour les plugins), c'est le cas, ça l'a toujours été et ne changera pas: les plugins existants resteront compatibles (d'ailleurs le numéro majeur considéré pour la libgimp est le premier, comme habituellement en semver, alors que pour le logiciel GIMP, c'est le second qui fait la majeure; donc notre API est encore plus conservative que le logiciel graphique, et c'est bien).
Personnellement le type de sortie continue que je vois, on ne ferait simplement plus de différence entre majeure et mineure. Simplement on pourrait sortir sans arrêt des mises-à-jour, que ce soit avec juste un correctif, ou avec une nouvelle fonctionnalité. Comme beaucoup de logiciels font de nos jours (notamment Firefox). Je sais que ça a fait jaser à l'époque de Firefox et que les gens ont cru que c'était juste un coup marketing (pour avoir le numéro de version le plus haut possible), mais je pense que cela pourrait vraiment libérer le développement. Pouvoir sortir des nouveautés sans arrêt, dès qu'elles sont vraiment finies, c'est super. Pourquoi s'encombrer avec des règles artificielles?
Bien sûr, il faudra garder des règles de compatibilité pour les plugins tout de même. Par exemple sur Firefox justement, les problèmes sont nombreux et beaucoup d'entre nous perdent des plugins régulièrement aux mises-à-jour. ;-( Un peu plus de stabilité serait bienvenu.
Donc en un sens, on peut garder les concepts de majeures et mineures mais limiter cela aux APIs ou aux changements graphiques vraiment profonds. Et c'est un peu la direction que nous prenons avec GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Version majeure / mineure
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Wilber Week, GIMP, interviews des développeurs et sortie de 2.10 à venir!. Évalué à 7.
Pourquoi? C'est qu'une question de définition. Hormis le fait qu'historiquement beaucoup de projets (dont GIMP) suivaient effectivement cette définition, tu peux tout à fait redéfinir, et dire par exemple qu'une version majeure, c'est quand tu changes quelque chose de... majeur justement (comme le moteur graphique, cas de GIMP 2.10, ou le toolkit graphique, cas de GIMP 3), et une mineure, c'est le reste.
D'ailleurs, si on souhaite se rapprocher du "versionnement sémantique", utilisé massivement, surtout pour des bibliothèques (peu les logiciels finaux) libres, tu peux tout à fait rajouter des fonctionnalités dans une mineure. Ce qui importe, c'est de le faire en restant compatible avec l'existant (tant qu'on ne change pas de version majeure). GIMP fournissant aussi une API (pour les plugins), c'est le cas, ça l'a toujours été et ne changera pas: les plugins existants resteront compatibles (d'ailleurs le numéro majeur considéré pour la libgimp est le premier, comme habituellement en semver, alors que pour le logiciel GIMP, c'est le second qui fait la majeure; donc notre API est encore plus conservative que le logiciel graphique, et c'est bien).
Personnellement le type de sortie continue que je vois, on ne ferait simplement plus de différence entre majeure et mineure. Simplement on pourrait sortir sans arrêt des mises-à-jour, que ce soit avec juste un correctif, ou avec une nouvelle fonctionnalité. Comme beaucoup de logiciels font de nos jours (notamment Firefox). Je sais que ça a fait jaser à l'époque de Firefox et que les gens ont cru que c'était juste un coup marketing (pour avoir le numéro de version le plus haut possible), mais je pense que cela pourrait vraiment libérer le développement. Pouvoir sortir des nouveautés sans arrêt, dès qu'elles sont vraiment finies, c'est super. Pourquoi s'encombrer avec des règles artificielles?
Bien sûr, il faudra garder des règles de compatibilité pour les plugins tout de même. Par exemple sur Firefox justement, les problèmes sont nombreux et beaucoup d'entre nous perdent des plugins régulièrement aux mises-à-jour. ;-( Un peu plus de stabilité serait bienvenu.
Donc en un sens, on peut garder les concepts de majeures et mineures mais limiter cela aux APIs ou aux changements graphiques vraiment profonds. Et c'est un peu la direction que nous prenons avec GIMP.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]