Là tu parles de changements majeurs, déjà ça n'arrive pas tous les jours.
Ensuite, pour l'exemple des bases de données, supposons que l'option "configuration partagée" ou "config cloud" ou appellation similaire, je dirais que la question ne se poserait pas:
-soit ta première utilisation de l'outil est la version Y qui utilise MongoDB et là effectivement, tu es coincé jusqu'à ce que ça migre partout ; mais à la configuration, tu peux afficher un avertissement
-soit ta première utilisation est sur la version X, et quand tu lances la version Y pour la première fois, et que le logiciel te le demande, tu ne cliques pas sur "créer une base MongoDB", mais "utiliser une configuration existante"
La migration vers MongoDB devra se faire, sûrement sur demande de l'utilisateur, plus tard, quand l'utilisateur se sera lui-même assuré que toutes ses versions peuvent le faire. (Mais avouons-le: ce n'est pas une solution pour les utilisateurs lambda).
Ou alors (plus compliqué!), on peut imaginer que le logiciel maintienne un journal également en ligne de tous les clients qui y accèdent avec leurs versions. Passé un certain temps, un client peut proposer une migration sur la base "tous les clients que vous avez utilisés depuis xxx temps sont capables d'utiliser la nouvelle génération de stockage de données, voulez-vous effectuer la migration vers la nouvelle génération?"
Beaucoup plus simple: l'accès aux données est fait via un wrapper, et le client connecté n'a pas besoin de savoir quelle base de données est utilisée derrière, il ne voit qu'une API. Les clients sont capables d'utiliser une partie ou la totalité de l'API suivant leur version.
[^] # Re: Configurations utilisateur
Posté par Maclag . En réponse à la dépêche Nix 1.7, Nixpkgs, NixOS 14.04, Guix 0.6. Évalué à 6.
Là tu parles de changements majeurs, déjà ça n'arrive pas tous les jours.
Ensuite, pour l'exemple des bases de données, supposons que l'option "configuration partagée" ou "config cloud" ou appellation similaire, je dirais que la question ne se poserait pas:
-soit ta première utilisation de l'outil est la version Y qui utilise MongoDB et là effectivement, tu es coincé jusqu'à ce que ça migre partout ; mais à la configuration, tu peux afficher un avertissement
-soit ta première utilisation est sur la version X, et quand tu lances la version Y pour la première fois, et que le logiciel te le demande, tu ne cliques pas sur "créer une base MongoDB", mais "utiliser une configuration existante"
La migration vers MongoDB devra se faire, sûrement sur demande de l'utilisateur, plus tard, quand l'utilisateur se sera lui-même assuré que toutes ses versions peuvent le faire. (Mais avouons-le: ce n'est pas une solution pour les utilisateurs lambda).
Ou alors (plus compliqué!), on peut imaginer que le logiciel maintienne un journal également en ligne de tous les clients qui y accèdent avec leurs versions. Passé un certain temps, un client peut proposer une migration sur la base "tous les clients que vous avez utilisés depuis xxx temps sont capables d'utiliser la nouvelle génération de stockage de données, voulez-vous effectuer la migration vers la nouvelle génération?"
Beaucoup plus simple: l'accès aux données est fait via un wrapper, et le client connecté n'a pas besoin de savoir quelle base de données est utilisée derrière, il ne voit qu'une API. Les clients sont capables d'utiliser une partie ou la totalité de l'API suivant leur version.
Évidemment, ça fait beaucoup de "yaka".