Aujourd'hui plus personne ne veut réellement de cycles de release qui se passent en mois. Y compris sur les logiciels desktop.
J'ai pas compris : selon toi les gens veulent des cycles plus long ou plus court ?
Mais bon avec un cycle de release long et une nouvelle version qui ajoute plus de bugs qu'elle n'en corrige c'est encore pire qu'avec un cycle court.
Pas forcément non, mais je me suis peut-être mal exprimé. Quand je parle cycle de release, ce sont les versions majeures, mais les corrections de bugs. petit exemple calqué sur les cycles Debian :
Logiciel version 1 (géré pendant 5 ans)
- v1.1 (maintenance : correction des gros bugs, sécurité, mais pas d'apport de nouveaux trucs)
- v1.2
- v1.3
Logiciel version 2 (nouvelle version majeure, plein de nouveaux trucs tout buggé)
- v2.1 beta (correction de bugs, etc.)
- v2.2 beta
- v2.3 stable
- v2.4 maintenance
l'utilisateur va pouvoir prendre la v1, qui sera géré par ex. pendant 5 ans, puis la 2.3 gérée pendant 5 ans. Il pourra ainsi capitaliser sur le fonctionnement du logiciel, qui ne variera pas.
Avec un tel cycle très banal, l'utilisateur (et le packageur) pourra avoir un logiciel stable. Le coût du changement sera moindre, puisqu'il a lieu tous les 5 ans. De même, le packageur pourra fournir dans Debian stable la version stable, et en testing la version moins stable mais plus à jour (2.1, 2.2)
Voici un autre exemple de cycle, en type rolling release inspiré de firefox :
Le logiciel a une version « master ». Tous les 2 mois, le master fournira la version courante. Pas de LTS.
Dans ces conditions, l'utilisateur aura toujours la dernière version. Lorsque l'équivalent de la version 2 arrive, il essuyera donc les pots cassés, ainsi que les éventuels problèmes de compatibilité (ah, le fichier enregistré avec la version 2 ne fonctionne pas sur le PC du collègue, qui lui à la 1.3...)
Il devra en permanence s'adapter aux changements du logiciel (interface, etc.), ce qui est coûteux.
Le packageur quand à lui sera obligé de packager toutes les versions, notamment pour les correctifs de sécurité, ou la correction des bugs les plus gros... Le coût sera plus important, puisque le logiciel changera sans cesse.
Ces deux cycles de release sont du vécu en tant que packageur. Après entre les 2 il y a plein de situations, qui peuvent fonctionner.
[^] # Re: Flatpak
Posté par Adrien . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 2.
J'ai pas compris : selon toi les gens veulent des cycles plus long ou plus court ?
Pas forcément non, mais je me suis peut-être mal exprimé. Quand je parle cycle de release, ce sont les versions majeures, mais les corrections de bugs. petit exemple calqué sur les cycles Debian :
Logiciel version 1 (géré pendant 5 ans)
- v1.1 (maintenance : correction des gros bugs, sécurité, mais pas d'apport de nouveaux trucs)
- v1.2
- v1.3
Logiciel version 2 (nouvelle version majeure, plein de nouveaux trucs tout buggé)
- v2.1 beta (correction de bugs, etc.)
- v2.2 beta
- v2.3 stable
- v2.4 maintenance
l'utilisateur va pouvoir prendre la v1, qui sera géré par ex. pendant 5 ans, puis la 2.3 gérée pendant 5 ans. Il pourra ainsi capitaliser sur le fonctionnement du logiciel, qui ne variera pas.
Avec un tel cycle très banal, l'utilisateur (et le packageur) pourra avoir un logiciel stable. Le coût du changement sera moindre, puisqu'il a lieu tous les 5 ans. De même, le packageur pourra fournir dans Debian stable la version stable, et en testing la version moins stable mais plus à jour (2.1, 2.2)
Voici un autre exemple de cycle, en type rolling release inspiré de firefox :
Le logiciel a une version « master ». Tous les 2 mois, le master fournira la version courante. Pas de LTS.
Dans ces conditions, l'utilisateur aura toujours la dernière version. Lorsque l'équivalent de la version 2 arrive, il essuyera donc les pots cassés, ainsi que les éventuels problèmes de compatibilité (ah, le fichier enregistré avec la version 2 ne fonctionne pas sur le PC du collègue, qui lui à la 1.3...)
Il devra en permanence s'adapter aux changements du logiciel (interface, etc.), ce qui est coûteux.
Le packageur quand à lui sera obligé de packager toutes les versions, notamment pour les correctifs de sécurité, ou la correction des bugs les plus gros... Le coût sera plus important, puisque le logiciel changera sans cesse.
Ces deux cycles de release sont du vécu en tant que packageur. Après entre les 2 il y a plein de situations, qui peuvent fonctionner.