An unimportant question out of curiosity, but one I’ve been asking myself since I started using dt, i.e. 3.x.
Why, after dt version x.8, do we go to x+1.0 rather than x.10?
For example, after 4.8 we have 5.0 and not 4.10. And from memory, it was the same for 4.0, which followed 3.8.
Usually, software version numbering follows the major.minor.patch pattern. But can we say that, perhaps by coincidence, 5.0 is a major version, just as 4.0 was, and if so, why is 5.0 (and 4.0) a major version?
Major releases usually introduce breaking changes. Could this be the case with 5.0 and the previous 4.0?
5.0 seems to me to bring essentially only interface and performance evolutions.
In FOSS and specially under Linux I have often seen this schema: <version>.<unstable odd, stable even>.<bugfix>, e.g. an officially released dt 4.8.1, the develop 4.9.x and now the official release 5.0
Yes @Macchiato17 , so what about GIMP currently downloadable in 2.10.38, for instance?
And even with the versioning scheme you’re presenting, we could have now 4.10 and the dev version would be 4.11…
I understand the first number is not related to any major breaking change in dt. Why not? So what makes a user know a new release holds breaking changes?
In a sense, darktable ‘never’ has breaking changes (except as bugs). Specifically, the intention is that you can open any past edit and continue working on it, or re-export it with identical (or nearly identical) results (unless the original output was due to a bug that has been fixed). Looking at it like that, one would never see new major versions.
However, the database and the xmp files do get updated, new modules get added. This does break compatibility in the sense that the newer database, or a newer xmp cannot be (at all, in case of the DB; properly, in case of a sidecar) opened using an older version. That warrants new major versions. I’m always on the current master branch (development version), so I see DB changes quite often. Maybe those also get released as minor versions, too.
Finally, ‘semantic versioning’ is not a must, just a possibility. If the developers see the amount of functional/non-functional (performance, usability etc.) changes warrants a new major version, they can choose to release one. Some projects simply use date-based version numbers (for example, Ubuntu 24.04, 24.10 etc); others (like OpenJDK) only use major and update/patch versions.
So to make it short, dt versioning is something like OpenJDK’s where a dot is added between tens and units.
4.8.1 could have been 48.1 and 5.0.0, 50.0, versions following a decimal progression.
“Major” versions 4, 5, etc… mean nothing special since it’s not the scheme followed.
Love that one too!