Compatibilité : à quel point ça sert ?

[pascal]

> Est-il possible de continuer à développer darktable en le faisant évoluer favorablement, tout en gardant la compatibilité avec les anciennes versions ?

Oui.

[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....

[techexo]

Je pense au final qu'on est tous d'accord à vouloir voir évoluer dartkable vers le meilleur ! La solution qui me paraît la plus simple est d'avoir 2 versions, même si l'une ne devrait être utilisée que "pour comparaison" ou pour les utilisateurs qui ont un besoin absolu de revenir à des développements précédents. Cependant il me paraît de toute façon impossible de bloquer les bonnes volontés des développeurs qui veulent faire évoluer les choses (pour le mieux pour autant que je comprenne), et le risque de refuser absolument toute évolution cassante sera l'avènement quasi-inévitable d'un fork... qui sera cassant d'une part pour le logiciel, mais peut-être aussi pour la communauté.

[bobo38]

Après avoir regardé la vidéo sur "l'ordre canonique" de aurelienpierre, je comprends mieux la nature de la discussion ici

Il semble que le pipeline de darktable soit figé et unique "by (software) design"; et qu'il soit perfectible. Avec une telle approche, toute amélioration serait une rupture de compatibilité : la pertinence de certains modules semble limitée par leur positionnement dans le pipeline, et non pas leur qualité propre

Avec un tel paysage, si je comprends bien une solution serait d'offrir la possibilité de créer des pipelines différents et de les faire cohabiter. Il semble y avoir une modification en cours de test pour repositionner des modules dans le pipeline, premier pas dans cette direction sans casser la compatibilité. Cependant une telle approche pourrait vite devenir un cauchemar de maintenance, puisqu'il introduit de la complexité supplémentaire, et ne résout pas le problème de fond:

Problème : on est obligé de trimbaler du code à moitié fonctionnel depuis parfois longtemps.

En tout cas chapeau aux gens qui maintiennent et développent ce projet !