I just observed that loading an image edited in January 2023 with version 4.4.0 into version 4.7.0+433~ga7852b83f6 (one of the latest nightly builds - today is Feb 2nd, 2024) - and deactivating a module with a caption in the top, will remove that caption.
In my DNG files it is replaced with the module counter, in the ARW files with spaces.
The original caption will exist in History for a short while (longer with people who forget to compress history ), but otherwise will soon be ⌠history.
I donât know if this is a bug or a calculated consequence of another database design. I also recently found out, that I canât go back from the nightly build in question, e.g. to 4.4.6, without having a message about - incompatible database. This means - redesigning and reloading in the older version, if I wanted to go back.
So, I stay with my environment and nightly builds.
Run a stable and dev from the master in parallel⌠turn off xmp writing in your dev version âŚBest of both worlds⌠also your db should be backed up from the old version likely if you look??
My personal editing will be in the devs. I will take a screen dump and write the captions back in the new base as they disappear.
Just wanted to point at this slightly annoying âstrippingâ phenomenon for those who havenât experienced it, and possibly for those who can do something about it.
I understand that returning to an older version of DT can provoke a compatibility problem, but the progressive development ought to be compatible with earlier editing.
there are plenty of hints thatâs recommended to have a backup when using development versions.
if you have enabled snapshots then you can copy the latest snapshot of your library.db to replace the current library.db
Martin: That older db would be missing days of intensive editing, so I think Iâll stay with my successive updating when needed. I know what I have now and donât want to experience other discrepancies with a swap.
development version is quite stable - at least when not using the new modules, colorequalizer, overlay and enlarge canvas. These might get further changes until final release that might break editsâŚ
That is not database design but design âhow to handle module headersâ and that has changed in 4,6
If you develop images on current master itâs not only the database that might be incompatible. While re-developing an image (old history letâs ays is from dt v4.0) on current master you will find some module parameters changed as a module might have got some more features so different module parameters.
In short, if you develop your image in master and try to use that image/sidecar pair on an old dt version (or a derivate) you might run into problems. But thatâs not a dt problem as i see it.
I understand this as:
If I edit my images in DT over a number of stable versions (i.e. for years), I need to keep a copy of all stable versions with its associated db to avoid missing this or that due to dev changes along the way?
If so, that would mean checking the XMP to open the right version of DT each time I want to edit old files.
If you are using different darkable versions, yes you have to keep the database as it is updated if you run a newer version and the databse wonât be usable be the old version afterwards. That is described clearly in the manual btw.
Opening an image previously developed on version ânâ using the sidecar will allow you open it again on any dt version â>= nâ or we would say, dt will ânot break old editsâ. But if you write sidecars here, they wonât be compatible any more with previous versions
Whenever you open an image and write sidecars - you can disable this behaviour - the sidecars will reflect the status of the darktable version in use. You can always use those image/sidecar pairs to develop again on older dt versions but there might be some issues and some things wonât work like new modules / algorithms.
So in short:
you are fine and donât have to worry if you just keep going and update dt to newer versions as all versions make sure, older stuff is taking care of.
If you want old and new versions in parallel, itâs more complicated - this use case is not intended by the dt dev team. There are several ways to handle this, using different databases ⌠I use some local git repo here for images and sidecars so i can switch between versions at least for the images i hold for testing âŚ
Just to make sure I understand the issue:
When you open an old edit in the later version of darktable, titles you added to modules disappear (NOT the modules, or the settings, JUST the âextraâ name of the preset or the name you gave that instance of the module)?
I think Iâve seen that as well. And it may be due to settings for those presets not being the same anymore. I have not seen any loss of edits, so Iâm not too worried about it. (and if itâs due to a change in the presets, it may be a good thingâŚ).
For what itâs worth, I havenât seen changes in dt yet that cost me edits, the devs make a big effort to maintain backwards compatibility. Forwards compatibility (using an old program version with newer sidecars/database) is much more difficult to ensure, and very restrictive on development (e.g. no new modules or new parametersâŚ).So most programs donât give that guarantee (or only in a very limited way, e.g. only for identical major versions)
But I donât use development versions. With those there is always a theoretical risk of incompatible changes (perhaps just for a few commits, but if you hit one of those fewâŚ).
), but otherwise will soon be ⌠history.