Compatibilité : à quel point ça sert ?

[palouf34]

Bonjour,

Je pense que "casser" la compatibilité de version est tout fait possible, n'en déplaise aux plus anciens utilisateurs.

Je m'explique, je reprend le cas "d’école" de python, lorsqu'ils ont décidé de casser la compatibilité , ils ont fait en sorte que dans les fichiers python "une simple instruction" indique que la version minimum à utiliser est la version 3., d'autre par le nom de l’exécutable porte le numéro de version majeur qui casse la compatibilité, même les dossiers de configuration et autres chemins on changé.

Alors pourquoi ne pas procéder comme suit:

pour la prochaine version de dt a savoir la 2.8:

• Un processus qui permet de modifier uniquement le fichier xmp pour rajouter une balise sur la version de dt en cours à savoir la 2.8. Vous allez me dire pour ceux qui possède une bibliothèque de plus de 10k raw, il suffit de réaliser le traitement en plusieurs lancement. Cette simple opération totalement transparente pour l'utilisateur peut être mise en place " très facilement".
  
• que cette version ne puissent tenir compte que de cette zone sans pouvoir  allez voire ce que contient la futur zone dt3
  
• Il faut "figer" cette version, pour les chemins d’exécutable,modules, configuration.
  

Cette simple modification prépare l'arrivé de la futur version qui casse la compatibilité

Maintenant pour la prochaine version, voici comment on peut envisager la chose.

• création d'un nouveau dossier de configuration  par recopie en one shoot de l'ancien dossier et donc de la base de données pour que cela soit totalement transparent pour l'utilisateur, avec juste un petit ralentissement au premier lancement.
  
• création d'un nouveau nom d’exécutable avec son arborescence à " la mode python", d'un nouveau paquet qui tient compte de l'ancienne version.
  
• modification des fichiers xmp en dupliquant la partie dédié à dt mais en changeant la balise  de version. Cela alourdi le fichier xmp et ceux bien sur en tenant compte de la volumétrie du catalogue. Vue le poids d'un fichier xmp, cette duplication interne, n'aura pas réellement d'incidence. 
  
• peut être prévoir une fenêtre  pour indiquer l'avancement de la conversion et surtout en prenant les fichiers à rebours pour ne convertir en premier que les fichiers les plus récent pour une base qui dépasse une certaine volumétrie ( cela doit être possible).
  

Cette solution permet de maintenir physiquement deux version de darktable sans bouger les précieux  fichiers tout en garantissant  pouvoir reprendre les modifications avec l'ancienne version. Comme darktable sait quant un xmp a été modifié, il est en capacité de récupérer les modifications dans la nouvelle version sans toutefois modifier ces paramètres.


Il est vrais que sur le site officiel cela oblige de conserver l'ancienne version/paquet dans les différentes distribution pendant longtemps sans aucun apport, mais regardez  python (même s'il y a eu des évolutions sur l'ancienne version)  conserve cette même ancienne version.


voila mon point de vue technique( développeur/informaticien),  je comprends que se sujet peut être chaud bouillant pour certain d'entre nous, mais je pense qu'il est plus que d'actualité et nécessaire pour pérenniser l'avenir de dt.

cordialement.


P.S.: pour ma part je n'ais pas une volumétrie très importante  pour pleurer ce changement, surtout que je conserve tout les fichiers jpg  générer.

P.S.S.: Un photographe qui conserve une bibliothèque énorme sans sauvegarde  régulière/purge est une totale hérésie. bref....