il y a moins de risque de surprises que si on fait juste ça deux fois par an
Pour les gros projets (voire pour les plus petits) on table plutôt sur de N années avec N entre 5 et 10 pour ce qui est de la couche système. Surtout si le projet met déjà un an à être mis en place. Ensuite l’application peut avoir ses propres cycles (si tant est que sa mise à jour reste compatible avec le socle système), c’est une autre histoire.
Du coup, à part les mises à jour de sécurité ou de bug sérieux il n’y a aucun changement des fonctionnalités de base du système, on n’est pas obligé d’utiliser les rétro-portages. Au bout des N années, si le projet perdure, il s’agit plus d’une migration de celui-ci. Permettant au passage d’améliorer ce qui peut l’être, car dans le laps de temps c’est potentiellement une partie de l’éco-système technique/middleware (sauvegarde, authentification, réseau, db, ...) qui aura aussi évolué.
Cela dit « l’autre » approche, avoir un/des OS/middleware qui évoluent rapidement, en continue, c’est sûrement une condition nécessaire pour pouvoir faire de même au niveau au niveau applicatif, plus précisément pour utiliser des applicatifs nouveaux qui sont développés dès le départ sur des socles récents.
Je pense qu’un SI doit savoir faire les deux, selon le besoin, même si ce « double pouvoir » a fatalement un coût.
[^] # Re: Red Hat != World
Posté par Marotte ⛧ . En réponse au journal Btrfs ne serait plus le futur. Évalué à 4. Dernière modification le 04 août 2017 à 20:25.
Pour les gros projets (voire pour les plus petits) on table plutôt sur de N années avec N entre 5 et 10 pour ce qui est de la couche système. Surtout si le projet met déjà un an à être mis en place. Ensuite l’application peut avoir ses propres cycles (si tant est que sa mise à jour reste compatible avec le socle système), c’est une autre histoire.
Du coup, à part les mises à jour de sécurité ou de bug sérieux il n’y a aucun changement des fonctionnalités de base du système, on n’est pas obligé d’utiliser les rétro-portages. Au bout des N années, si le projet perdure, il s’agit plus d’une migration de celui-ci. Permettant au passage d’améliorer ce qui peut l’être, car dans le laps de temps c’est potentiellement une partie de l’éco-système technique/middleware (sauvegarde, authentification, réseau, db, ...) qui aura aussi évolué.
Cela dit « l’autre » approche, avoir un/des OS/middleware qui évoluent rapidement, en continue, c’est sûrement une condition nécessaire pour pouvoir faire de même au niveau au niveau applicatif, plus précisément pour utiliser des applicatifs nouveaux qui sont développés dès le départ sur des socles récents.
Je pense qu’un SI doit savoir faire les deux, selon le besoin, même si ce « double pouvoir » a fatalement un coût.