Releasing and tagging

We started using a tag-based approach to handle which commit is used in the stable KNIME versions that are currently supported. Usually KNIME offers support for the latest two minor versions (e.g. at the time of writing this is 3.1 and 3.2). Since GKN may become incompatible between two KNIME versions, we need a way to make sure that the correct GKN versions ship with the KNIME Community Contributions. That means if there is a new release here, test it with as many of the current KNIME versions that are still supported (as mentioned usually the last two) and upgrade the tags to the last release that was working for a specific KNIME version. Use tags that correspond to the numbering on the KNIME Community Jenkins Server:

knime/${KNIMEVERSION}

Please also tag the latest version with

knime/latest

for automation convenience.

The develop branch should always be compatible with the latest KNIME version since its HEAD is used for the trunk builds of the Community Contributions.

Since it is a linear tag-based approach, new features will usually not be merged to legacy releases of the GKN. If there are important bugfixes for older versions:

1. Think about if they are really important
2. Branch off that release
3. Try to merge the bugfix commits or incorporate the fixes from scratch
4. Update the tags to the HEAD of that branch.