28-01-19, 23:55
Je remets mon avis déjà donné dans un autre fil.
Pour compléter cela, après avoir lu les messages de ce fil : j'ai cru comprendre qu'il était possible de 1) marquer des modules comme obsolètes ; 2) conserver ces modules dans le pipeline, même si pas affichés (??). Dans ce cas, pourquoi ne pas partir avec une nouvelle version majeure avec :
- la duplication de tous les "module" en "module_ng" ;
- l'affichage par défaut de seulement les "module_ng" dans l'interface ;
- la concentration du développement uniquement sur les "ng"
Ainsi, darktable serait toujours capable de charger les vieux "module" de vieux XMP, avec des réglages qui fonctionnent toujours, et des exports possibles et identiques (pour les photographes ayant besoin de recharger/réexporter des images déjà traitées) ; mais par défaut les nouveaux modules sont ceux où les améliorations continues seront faites. On pourrait imaginer une option dans les préférences de darktable permettant de n'afficher que les modules "ng", ou d'afficher les modules "legacy" pour les personnes qui ont absolument besoin de traiter des anciens développements.
Je pense que ça implique des efforts au départ, avec des doublons qui vont être extrêmement casse-noisettes à gérer, mais ça permettrait un virage progressif vers des nouveaux modules pour tous ceux que ça ne dérange pas. Quitte à un jour déprécier totalement les "legacy".
Il serait aussi envisageable (sur une base volontaire, bien entendu), de sonder les modules utilisés en scannant les fichiers XMP de la bibliothèque, et voir quels modules sont réellement utilisés, à quelles fréquences etc. Je pense que certains modules apparaitraient alors sous un jour différent (très utilisés ou alors totalement abandonnés, cela donnerait des arguments en faveur d'une dépréciation ou d'un effort de développement).
Citation :La première remaruque est : dans un contexte de production professionnel de photos, à quelle fréquence on retournera à des vieilles photos déjà traitées ? Si la réponse est "rarement", la question de la rétrocompatibilité est à mon avis superflue tant que l'on peut avoir deux versions de darktable en parallèle. Je suppose qu'un photographe dont c'est le boulot créé suffisamment de matériel pour travailler surtout sur ses dernières œuvres, mais peut-être me trompe-je.
La seconde : dans le cas d'un fork vers un "nouveau darktable" (que j'appellerai -ng), il devrait être possible d'ajouter la version de darktable dans les fichiers XMP et afficher un avertissement "Vous travaillez sur un développement effectué avec une version antérieure de darktable, le rendu risque d'être différent" si l'on ouvre avec darktable-ng, avec un bouton "OK j'update le XMP et j'éditerai ce fichier avec darktable-ng dans le futur". L'utilisateur ferait ainsi le choix volontaire de profiter des nouvelles fonctionnalités de -ng, en toute connaissance de cause.
Enfin, l'exemple de Python est comme cela a déjà été mentionné à double tranchant. Toutefois, il est indéniable que 1) les débutants ne font plus de Python2 ; 2) les développeurs Python, même chevronnés, goûtant aux fonctionnalités spécifiques de Python3 retournent rarement en arrière, particulièrement pour les dernières versions ! 3) il reste tout à fait possible d'avoir les deux en parallèles (même si c'est particulièrement c****t de passer tout le temps de l'un à l'autre). Enfin, sans insulter la communauté darktable, je pense que son impact est tout de même moindre que celui de Python dans le paysage informatique mondial.
De mon point de vue (naïf), je pencherai plus pour un changement de version majeur (darktable3?) afin que la communauté de traducteurs/porteurs/testeurs ne partent pas en courant ; si possible après une négociation avec les développeurs historiques. Dans tous les cas, merci à tous les devs actifs !
![[Image: smile.png]](https://forums.darktable.fr/images/smilies/smile.png)
Pour compléter cela, après avoir lu les messages de ce fil : j'ai cru comprendre qu'il était possible de 1) marquer des modules comme obsolètes ; 2) conserver ces modules dans le pipeline, même si pas affichés (??). Dans ce cas, pourquoi ne pas partir avec une nouvelle version majeure avec :
- la duplication de tous les "module" en "module_ng" ;
- l'affichage par défaut de seulement les "module_ng" dans l'interface ;
- la concentration du développement uniquement sur les "ng"
Ainsi, darktable serait toujours capable de charger les vieux "module" de vieux XMP, avec des réglages qui fonctionnent toujours, et des exports possibles et identiques (pour les photographes ayant besoin de recharger/réexporter des images déjà traitées) ; mais par défaut les nouveaux modules sont ceux où les améliorations continues seront faites. On pourrait imaginer une option dans les préférences de darktable permettant de n'afficher que les modules "ng", ou d'afficher les modules "legacy" pour les personnes qui ont absolument besoin de traiter des anciens développements.
Je pense que ça implique des efforts au départ, avec des doublons qui vont être extrêmement casse-noisettes à gérer, mais ça permettrait un virage progressif vers des nouveaux modules pour tous ceux que ça ne dérange pas. Quitte à un jour déprécier totalement les "legacy".
Il serait aussi envisageable (sur une base volontaire, bien entendu), de sonder les modules utilisés en scannant les fichiers XMP de la bibliothèque, et voir quels modules sont réellement utilisés, à quelles fréquences etc. Je pense que certains modules apparaitraient alors sous un jour différent (très utilisés ou alors totalement abandonnés, cela donnerait des arguments en faveur d'une dépréciation ou d'un effort de développement).