Release strategy for the repository

[hnicolaysen]

Hello everybody!

Lately, there were multiple discussions ongoing which all go down to one root cause: A missing release strategy for this repository.

Generally, the fear of breaking changes is generally high since there are multiple systems relying on a proper functionality. This was proven with changes introduced in #80 and it is also the reason for very sparse responses by gridX when it comes to pull requests. At gridX, the Integrations team's staff fundamentally changed. Thus, implications of changes are often not clear which creates a lot of precociousness.

In #80 (comment), @andig already mentioned the need of a proper release strategy and we totally agree with that. This is why I'd like to kick off a discussion here to improve the process to meet everyone's needs.

We would like to start the discussion with a

First proposal:

Generally, the change frequency is relatively low. Therefore, we believe that a manual release strategy could already suffice. I.e., whenever someone wants to impose a change into their external project, we could just create a release with an incrementing number (e.g. 1.3, 1.4, ...). This would give everyone the freedom to either keep up with the latest release or to use an older one by referring to it's release tag.

Discussion

What do you think about this idea? Does it suffice for everyone? Is there anything to consider here?