Proposal for maintenance release strategy alignment

[peanball]

Unify the approach, how maintenance releases are managed in git and GitHub.

Easier viewing of the whole document: https://github.com/sap-contributions/ironcore-enhancements/blob/release-branching/ieps/tbd-release-branching.md

[friegger]

LGTM, I support the proposed solution.

[mkalcok]

The main proposal makes the most sense to me for the current pre-v1 development. The alternatives seem more suitable for "after-v1" development, where major releases are further apart and better defined in terms of features/compatibility.

I'm not even sure that this drawback of the main proposal applies:

Determining the 'branching off point' for the maintenance branch is not as clear-cut and may require manual intervention or complex logic.

If you need to backport a fix, and the maintenance branch doesn't exist yet, you can just use the tag to determine where to branch from, right?

[peanball]

@mkalcok

I'm not even sure that this drawback of the main proposal applies:

Determining the 'branching off point' for the maintenance branch is not as clear-cut and may require manual intervention or complex logic.

If you need to backport a fix, and the maintenance branch doesn't exist yet, you can just use the tag to determine where to branch from, right?

Yes, as human the logic is pretty clear. What I was alluding to was if we were to automate something to back port a particular PR, the release branch may need to be created on the fly, based on the latest available tag (semver) to branch off of. "Manual intervention" is then the part of seeing it easily as a human and making a branch at the appropriate tag. Complex logic is to do correct semver and semver parsing. I will add a note that this drawback is about automation.

[mkalcok]

@mkalcok

I'm not even sure that this drawback of the main proposal applies:

Determining the 'branching off point' for the maintenance branch is not as clear-cut and may require manual intervention or complex logic.

If you need to backport a fix, and the maintenance branch doesn't exist yet, you can just use the tag to determine where to branch from, right?

Yes, as human the logic is pretty clear. What I was alluding to was if we were to automate something to back port a particular PR, the release branch may need to be created on the fly, based on the latest available tag (semver) to branch off of. "Manual intervention" is then the part of seeing it easily as a human and making a branch at the appropriate tag. Complex logic is to do correct semver and semver parsing. I will add a note that this drawback is about automation.

Ah, makes sense, thanks for the clarification. I was assuming human intervention for these backports.

[peanball]

@mkalcok

Ah, makes sense, thanks for the clarification. I was assuming human intervention for these backports.

Clarified with e916d36 in the proposal as well.