There is more and more people using the dev release, and that’s fine. This ensure that the new features are tested early and we get bug report in time for the releases.
But just remember that even if we try hard to keep compatibility with old edits, it may be possible that on the dev releases we break compatibility if for example keeping two slightly different algorithms would require too much maintenance.
Have all and happy new year with darktable !
15 posts were split to a new topic: lens correction and denoise on by default
Wise advice, duly noted. I am fine on git master and I am aware of what I am doing, backwards compatibility can be lost.
Happy 2024
Thanks Pascal for this timely reminder. This would obviously be true for when we also upgrade to the latest stable releases every six months. For me it is not a problem as I am happy to reedit my images with improved tools and improved skills that I develop over time. I always export my edits as 16 bit tiff files to archive my edit and if I ever want to return to that image I normally want to start from scratch again anyway.
I am looking forward to trying the 4.7 insider builds for Windows and seeing what new improvements come in 2024 from the great development team.
Not so much. Usually those compatibility breaks are between commits in master (from one day/week to the next) rather than between current stable and current master. They are often fleeting in nature (a release on a Friday might break edits that were made on the Monday), so will more commonly affect people who update master frequently.
The devs do try very hard not to break compatibility between one stable release and the next, and would consider it a pretty big failure if a new stable release broke edits made on an old stable release. But sometimes breaking edits from last week within master is a price worth paying for less complex code.
Thanks for the clarification. Good to know.
I’ve been using darktable for a long time and I still only ever use the stable builds for my daily edits as I don’t think it’s worth the risk. I maintain a separate master build to play with but just with a small sample set of raw files (mostly PlayRaws from this forum).
Since I self-build, my daily driver usually tracks the stable development branch (which is the last feature release plus some fixes due for the next fix release – so still pretty stable and low-risk) and then I track master for a few weeks before a feature release (usually after the feature freeze) so that I can test and raise any issues before the final release is created.
Exactly as @elstoc said, and I’d like to add that we are running 157 tests every night to ensure that the output is close (< 2dE) to the expected one. Those tests are using full darktable pixelpipe and exercising each one or two modules. All modules are covered. We start from a RAW (Bayer or X-Trans) and do a development of the image using an XMP from the command line.
That’s impressive and re-assuring.
I’m in awe of how you developer guys steadily work to improve the tool, and I’m very grateful for having the result made available for own use. Thanks a lot to all!
I ride master and use it as my daily driver. I’m now pretty good at bisecting 
. I haven’t had many problems other than the occasional won’t compile. In that case I just check out an earlier commit and work from that until the problem is fixed.
The biggest thing to be wary of is database upgrades, since you can’t go back unless you have a backup. So I recommend letting the database backup and writing the XMP files (just in case).