Release process

[vladar]

Hey @spawnia and @simPod

Let's discuss some administrative questions. I've created a new branch for 14.x version maintenance. Master is open for breaking changes for version 15.x. But for bugfixes - we should merge them to master first and then cherry-pick to 14.x branch (to avoid regressions).

Patch releases for 14.x should be made from the corresponding 14.x branch. Please let me know what you think.

Just want to make sure we don't publish breaking version from master as 14.x.y accidentally 😅

[simPod]

I agree (though I wouldn't dare to release myself, prefer @spawnia to do it 😅)

Also we can rename master to 15.x eventually.

[vladar]

Also, I've created two labels:

• backport-to-v14 (add it to PRs that must be backported to 14.x branch)
• backported-to-v14 (add this when you've backported some PR, and remove the backport-to-v14 label)

[mfn]

Sorry to jump in here 👋

Isn't it easier to maintain merges into lower branches, e.g. merge into 14.x and then just merge it to master?

The requirement here is to decide if a PR if it should go into 14.x or straight master, depending what kind of change, but otherwise it might be easier?

[spawnia]

I think this project is moving at a pace that requires no particular coordination around this process. I think both approaches will work fine.

Also, I am not expecting that much maintenance of old branches is going to happen anyways. If someone wants to backport fixes, that is fine with me - I am going to focus on moving the newest version forward instead.

[spawnia]

Sounds good, such maintenance branches have worked nicely in my experience. I am excited to break some stuff now 💥