Repository branches based on darktable version

[wpferguson]

Problem

During the darktable 3.5 development cycle numerous changes were made to the darktable lua API. In an effort to make the API changes available to the users of darktable 3.5, various workarounds were implemented in the master tree. While this has worked, for the most part, it's somewhat of a nightmare to maintain and can/has introduced some unpleasant surprises.

Going Forward

I propose that the master branch will track the current darktable release as far as API is concerned.

New versions of scripts that take advantage of API changes/additions will be kept in a new branch tracking the development version of the API.

When a new version of darktable is released the following will happen:

• Current master will be tagged with the previous version of darktable (i.e. when darktable 3.6 is released, then the lua scripts master branch will be tagged darktable-3.4.x). This way someone running an older version of darktable can still use the scripts, they just have to checkout the tag for the version of darktable they are using (script_manager could be modified to handle this).
• The branch containing the newest API changes will be merged into master. A new branch will be created to contain the next round of API changes.

To be figured out

• do we have a bugfix branch for older versions of the API. If so, how long do we maintain older versions?
• whatever I didn't think of :smiley:

[wpferguson]

@supertobi what are your thoughts?

[supertobi]

I'm fine with the changes.

If so, how long do we maintain older versions?

I'm able and willing to support older versions as long as I have an older version installed. And I will not stop anyone to provide patches for older version. But I'll not build an test suite with n darktable versions.

[wpferguson]

I cloned the repository locally and tagged the last commit before an API change with the, at that time, current API version. My thought is to make script_manager smart enough to check the API version of darktable, then checkout the appropriately tagged version.

I'll play with checking out a tagged version, then creating a bug fix branch, then seeing what I can do from there. I may have to make script_manager smart enough to use the bug fix branch if it exists, otherwise use the API version tag.

I'm able and willing to support older versions as long as I have an older version installed. And I will not stop anyone to provide patches for older version. But I'll not build an test suite with n darktable versions.

I'm still running Ubuntu 18.04 so I can compile old versions pretty easily. When I finally make the jump to 20.04 (or 22.04) I'll probably build an 18.04 VM just so I can compile old versions in case I need to test against them.

Thanks for the feedback.

[wpferguson]

Changes are reverted back to API 6.1.0 in master branch. API-7.0.0 changes are currently in a branch called API-7.0.0-dev. When darktable 3.6 is released, the API-7.0.0-dev branch will be merged to master.

Still exploring the best way to manage the old API versions and compatibility. Tags are the easiest, but don't easily allow for bug fixes or backports, but I'm leaning toward branches for each released API version back to 4.0.0 (dt 2.2).

[wpferguson]

Added branches for 4.0.0, 5.0.0, 5.0.1, 5.0.2 and 6.0.0. Will add a branch for 6.0.1 and merge 7.0.0 branch to master when darktable 3.6 is released.

[wpferguson]

Done. API-7.0.0-dev branch merged to master and is now current. script_manager is API aware so an older version of darktable will get the correct scripts. Bug fixes can be back ported to API branches as necessary.