Pour répondre à tes questions, pour moi, garder la compatibilité est peu important, je n'ai pas beaucoup de raw en stock. Tous les raws qui m'intéressent sont déjà convertis en jpeg.
Ce ne sont que des photos de vacances, donc pas de contraintes, ni professionnelles, ni associatives ou autre
J'ai une bd assez légère aussi.
J'ai pris l'habitude (déjà ! grgr) de supprimer de la bd, les "dossiers" traités, mon ordi étant trop léger.
Donc, si besoin, je réimporte un dossier, un fichier. Le catalogage est donc pour l'instant pas important, même si je passe du temps à taguer et que je me suis déjà fait qq règles.
Alors, évidemment, je suis à fond pour une V3.0.0 de dt.
Je prends maintenant ma casquette de développeuse ( php avec framework symfony). On peut faire le parallèle "développeur dt" et "développeur php avec symfony". Tout comme pour dt, je ne connais pas (n'ai pas à connaitre) le code "profond" de symfony.
Je suis confrontée régulièrement à cette question "upgrade or not upgrade".
Dans ce framework, chaque nouvelle version majeure est accompagnée de versions mineures permettant de préparer la migration.
Avant de passer à la 3.0.0, les version 2.8.X, en plus des nouveautés, corrections, nous informe des futures fonctionnalités dépréciées, ce qui nous permet, soit de préparer en douceur la migration, soit de se dire tout simplement : je ne migrerai pas, trop de taf !
Est-il envisageable d'avoir une telle fonctionnalité dans une version 2.6.x ou 2.8.x de dt ?
par exemple :
- en ajoutant une surimpression dans la table lumineuse ou un css spécifique pour les images concernées
- en ajoutant des tags dans la catégorie darktable : version, migration (possible, pas possible ou autre)
Cela permettrait d'évaluer/préparer avant de migrer en filtrant les fichiers concernés en fonction de ses besoins (notes, tags ou autre + tag dt de migration)
Je trouve aussi l'idée des clones très intéressante.
Pour toutes les photos qui "ne passent pas" ou partiellement, créer un clone de "version" peut-être avec une numérotation spécifique correspondant à la version de dt + numérotation du clone, si besoin.
Je crois me souvenir que quelqu'un avait fait le parallèle avec python et la possibilité d'avoir plusieurs versions d'installées et de choisir laquelle utiliser. C'est peu-être trop compliqué pour dt ?
Je sais que cela rajoute du taf et que vous en faites déjà beaucoup.
Brider des devs bénévoles, c'est pas bon non plus.
Aurélien, tu comptes reprendre vraiment beaucoup de modules et donc n'avoir aucune compatibilité ?
Est-il possible d'avoir une version de dt ou plutôt un script juste pour faire l'inventaire de ce qui ne sera pas compatible pour aider les personnes concernées à faire un choix ?
(pour le script, je peux aider, pour le c, trop dur pour moi)
Ce ne sont que des photos de vacances, donc pas de contraintes, ni professionnelles, ni associatives ou autre
J'ai une bd assez légère aussi.
J'ai pris l'habitude (déjà ! grgr) de supprimer de la bd, les "dossiers" traités, mon ordi étant trop léger.
Donc, si besoin, je réimporte un dossier, un fichier. Le catalogage est donc pour l'instant pas important, même si je passe du temps à taguer et que je me suis déjà fait qq règles.
Alors, évidemment, je suis à fond pour une V3.0.0 de dt.
Je prends maintenant ma casquette de développeuse ( php avec framework symfony). On peut faire le parallèle "développeur dt" et "développeur php avec symfony". Tout comme pour dt, je ne connais pas (n'ai pas à connaitre) le code "profond" de symfony.
Je suis confrontée régulièrement à cette question "upgrade or not upgrade".
Dans ce framework, chaque nouvelle version majeure est accompagnée de versions mineures permettant de préparer la migration.
Avant de passer à la 3.0.0, les version 2.8.X, en plus des nouveautés, corrections, nous informe des futures fonctionnalités dépréciées, ce qui nous permet, soit de préparer en douceur la migration, soit de se dire tout simplement : je ne migrerai pas, trop de taf !
Est-il envisageable d'avoir une telle fonctionnalité dans une version 2.6.x ou 2.8.x de dt ?
par exemple :
- en ajoutant une surimpression dans la table lumineuse ou un css spécifique pour les images concernées
- en ajoutant des tags dans la catégorie darktable : version, migration (possible, pas possible ou autre)
Cela permettrait d'évaluer/préparer avant de migrer en filtrant les fichiers concernés en fonction de ses besoins (notes, tags ou autre + tag dt de migration)
Je trouve aussi l'idée des clones très intéressante.
Pour toutes les photos qui "ne passent pas" ou partiellement, créer un clone de "version" peut-être avec une numérotation spécifique correspondant à la version de dt + numérotation du clone, si besoin.
Je crois me souvenir que quelqu'un avait fait le parallèle avec python et la possibilité d'avoir plusieurs versions d'installées et de choisir laquelle utiliser. C'est peu-être trop compliqué pour dt ?
Je sais que cela rajoute du taf et que vous en faites déjà beaucoup.
Brider des devs bénévoles, c'est pas bon non plus.
Aurélien, tu comptes reprendre vraiment beaucoup de modules et donc n'avoir aucune compatibilité ?
Est-il possible d'avoir une version de dt ou plutôt un script juste pour faire l'inventaire de ce qui ne sera pas compatible pour aider les personnes concernées à faire un choix ?
(pour le script, je peux aider, pour le c, trop dur pour moi)