Workflow for maintaining OSP-core v3.x.x and v4.x.x simultaneously

[kysrpex]

Many users of OSP core need new features that involve breaking changes, and they need them quickly.

With the current branching workflow, such breaking changes would have to be incorporated to dev, together with non-breaking changes, such as bugfixes or backwards-compatible new features. This would mean that the next version to be released would involve a change in the major version number. Users that need one of the bug-fixes or the backwards-compatible new features would have to adapt immediately to support the breaking changes. Moreover, putting together a new major version can take some time, and during all such time bug-fixes, that sometimes are critical, would be unavailable.

In order to avoid this situation but still support the users that need the new feature, it makes sense to have another dev branch for such new major version, so that the users can use it even while it is in the works. Moreover, another main branch could be created for the next major version release when it's ready.

After the next major version is released, during some time, both major versions could be maintained. Maybe only bug-fixes would be backported to the old major version. This would be a transition period during which users can familiarize with the new major version and adapt their code.

The purpose of this discussion is to propose a workflow that achieves this.

[pablo-de-andres]

Do we need the second main for the breaking changes? Since the breaking changes will start as quick fixes, I think keeping them in a dev branch sounds reasonable, as a sort of pre-release. And when they are stable and tested enough, they could maybe just go to the standard main.

I see the reasoning behind a second one, but fear it might create a lot of overhead.

[kysrpex]

[kysrpex]

With regard to @pablo-de-andres's question:

Do we need the second main for the breaking changes? Since the breaking changes will start as quick fixes, I think keeping them in a dev branch sounds reasonable, as a sort of pre-release. And when they are stable and tested enough, they could maybe just go to the standard main.

I see the reasoning behind a second one, but fear it might create a lot of overhead.

I understand the concern that it might create a lot of overhead. However, people will not update to the new major version immediately I guess. If during this transition period there is an issue like a library that is updated, breaking compatibility, like it happened with rdflib, websockets, rdflib-jsonld; or a critical bug appears, then the only alternative for this people is to migrate immediately to the new version. Do we really want to force them to do so? This can understandably, make people angry.

The important point to think of there is: we are not going to put in the old major version any new features that are not easy to backport from the latest major version (or none at all). This means we will perform this complex procedure few times, but we will keep everybody happy during this transition period.

Also, obviously when the new major version is released, release/4/main would be merged to master (and then deleted), release/4/dev woud be deleted. dev would be deleted and recreated from master. Two new branches would be created from the latest commit before the merge to master: release/3/main and release/3/dev.

[kysrpex]

I deleted release/4/main as a result of the previous thoughts.