Rolling release

Dans le domaine du développement logiciel l'approche rolling release (littéralement « publication roulante », soit « publication continue ») fait référence à un système de développement logiciel en continu, par opposition au système par version, où l'on procède à des mises à jour en production qu'à la fin du cycle de développement d'une version du logiciel ou du système tout entier. Il s'agit donc d'un des nombreux types de cycles de vie de publication d'un logiciel.

Il est notamment utilisé par certaines distributions Linux. Un système rolling release est généralement implémenté par la mise en œuvre de petites et fréquentes mises à jour. Cependant, appliquer des mises à jour régulières ne signifie pas nécessairement faire usage d'un système en rolling release. Pour qu'une telle dénomination s'applique, les développeurs doivent utiliser une méthode de travail avec une branche unique, par opposition à des versions spécifiques à une étape du cycle (par exemple versions de développement, de test et de production). Dans un système de rolling release les mises à jour sont généralement fournies via un gestionnaire de paquets à travers une connexion internet.

Exemples

Gentoo Linux, Arch Linux, Sabayon Linux, Foresight Linux, KahelOS, Frugalware, Linux Mint Debian Edition et PCLinuxOS sont de vrais exemples de distributions en rolling releases. Le média d'installation est tout simplement un aperçu provisoire de la distribution au moment de sa sortie. Les logiciels contenus dans les dépôts sont plus récents que ceux contenus sur les médias d'installation.

D'autres distributions GNU/Linux peuvent maintenir une branche de développement entre deux versions successives. Ces branches de développement peuvent ressembler aux rolling releases parce que les logiciels dans de telles branches sont continuellement mis à jour. Cependant, contrairement aux rolling releases, ces branches sont destinées à être la prochaine version, et seront gelées et testées avant la publication d'une version. Les branches testing et unstable de Mandriva Cooker, openSUSE Factory, Fedora Rawhide, et Debian sont des exemples de ce type de développement. L'utilisation de ces branches de développement dans un environnement de production est à déconseiller, dû à des risques d'instabilité, de sécurité, etc.

Toutefois, La branche testing de Debian contient les paquets de la prochaine version stable, le flot de paquets n'est donc pas tout à fait continu. De la même façon chez Frugalware, où les paquets ne sont pas continus dans la version « current » pour préparer la prochaine version stable.

Il arrive également que les distributions suivent un modèles half-rolling release, littéralement publication par demi-roulement : les paquets importants du système sont soumis à des tests tandis que les logiciels comme les navigateurs webs, suites bureautiques, outils multimédias, jeux, etc., sont mis à jour continuellement. Exemple : Chakra Linux qui mets à jour les paquets critiques du système tous les 6 mois.

Aptosid (ex-sidux) et Aurora OS (ex-Eeebuntu) sont des rolling releases Linux basées sur Debian et sa branche de développement unstable (sid). Outre des dépôts de Debian unstable, Aptosid utilise ses propres dépôts de paquets et ses outils pour aider à éviter un éventuel crash (assez fréquent lors de l'utilisation de Debian unstable).

Contre-exemples: Windows, Mac OS, OpenBSD, et beaucoup de distributions GNU/Linux (Debian, y compris la version « stable ») ne sont pas des rolling releases, car d'importants changements sont réalisés entre versions successives (une réinstallation complète du système d'exploitation, ou du moins une mise à jour majeure, est nécessaire). Cela entraîne également un effort de développement important pour garder à jour les anciennes versions, en raison de la propagation de correctifs de bogues en provenance de la dernière branche, au lieu de se concentrer davantage sur la branche de développement la plus récente.

On peut cependant chez pas mal de distributions Linux installer les versions de logiciels compilés et/ou empaquetés pour sa distribution :

• Par le biais d'un site comme gtk-apps, gnome-files ou kde-apps.
• Par le biais du site officiel ou d'un site tiers, en téléchargeant les sources et en les recompilant soit-même, sous forme de script qui installe les composants par le biais des dépôts de la distributions ou de fichiers trouvable en téléchargement sur d'autres sites (ex : pkgbuilds d'archlinux), ou encore une archive/fichier binaire tout prêt.
• Par le biais de dépôts non-officiels, comme par exemple les PPA d'Ubuntu.

Concentration de l'effort

Il est courant de prendre à l'occasion un instantané (snapshot) de la rolling release, pouvant être raffiné et «gelé», et gardé uniquement par sécurité (comme Frugalware avec la branche current (rolling release) et stable (paquets gelés)). Cela n'est souvent pas pratique, car cela nécessite la multiplication des efforts. En règle générale, les défauts et les caractéristiques d'une release particulière ne sont pas spécifiquement abordées dans un effort distinct/isolé (par exemple, patches) ; au contraire, elles sont traitées dans l'effort principal de développement.

Notes et références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Rolling release » (voir la liste des auteurs)

Voir aussi

• Release engineering

• Portail de l’informatique