Naming convention for Maintenance branches and branch protection rule for them

[hdamker]

Problem description

Do we have already a naming convention for maintenance branches to enable patch release after the M4 release of a working group and/or API repository? The Guideline is currently only saying "the patched public API version x.y.z+1 shall be created through a maintenance release on a separate branch referred to as a maintenance branch"

In addition we need an additional branch protection rule in all repositories which will protect the maintenance branches like the main branch.

Possible evolution

A naming convention for maintenance branches is defined and added to https://github.com/camaraproject/ReleaseManagement/blob/main/documentation/API_Release_Guidelines.md.

A branch protection rule which covers these branch names is rolled out across all repositories.

Proposal:

maintenance-rx, created based on the release tag rx.n+1 (the M4 release) within the main branch. The first patch release on the maintenance-rx branch is then rx.n+2.

Exceptions for Commonalities and ICM within Fall24 Meta-Release: maintenance-r0.4 respective maintenance-r0.2 (but only for Fall24, proposal is that they follow in next release cycles also the rx.n format. Issue for that to be created).

Proposal for the branch protection rule is to extend the pattern for the current rule from main to main* which has the advantage that no new rule has to be created and for new repositories still only one rule need to created. That would protect all branches which start with "main" - which shouldn't be a problem as branches for PR development should be in forks of the upstream repository not in the repository itself.

Alternative solution

Additional context

camaraproject/IdentityAndConsentManagement#196 is waiting for a decision on this issue.

[tanjadegroot]

In the Confluence https://wiki.camaraproject.org/display/CAM/API+Release+Process > Maintain a public release > PATCH update we have "the branch name shall be maintenance-rx.y where rx.y is the release number of the public release rx.y being patched"

The branch naming is not explicitly stated in the GitHub version of the API release process, so this would need an updata

[hdamker]

"the branch name shall be maintenance-rx.y where rx.y is the release number of the public release rx.y being patched"

A patch release is also a public (or in GitHub language a "latest"), right?
That would imply that for each patch release there will be a new maintenance branch, not necessarily a problem, as we don't expect many patch releases between the release cycles (not sure about this ...).

But another point is for me that there will be potential confusion as such branch "maintenance-rx.y" could be understood that it is there to develop the release rx.y.

For the two reason I'm still in favour of my proposal with "maintenance-rx", one branch per metarelease which will be used to maintain the meta-release.

BTW: how we want to deal with the situation of patch releases of rx if there is already the next public release rx+1.n as "latest". It wouldn't make sense to declare a rx.p as a "pre-release" to avoid to overwrite the rx+1.n. But that seems to be mainly a GitHub UI problem.

[jpengar]

It's not 100% clear to me what a working group should do with the maintenance branch, I think at some point the changes applied to that branch should be merged into the main branch as well, to be included in the next meta-release as well. Right?
Normally, maintenance branches would contain fixes that we would most likely want to merge into the next releases as well...

[hdamker]

It's not 100% clear to me what a working group should do with the maintenance branch, I think at some point the changes applied to that branch should be merged into the main branch as well, to be included in the next meta-release as well. Right?
Normally, maintenance branches would contain fixes that we would most likely want to merge into the next releases as well...

The maintenance branch allows to create patch releases of previous released versions, while the main branch contains already changes (wip) towards the next version. For example you released for Fall24 v1.0.0 with r1.2, in the main branch there are already changes which are planned to released as v1.1.0. If you now want to create a patch version v1.0.1 (e.g. with a documentation fix), you need to create a maintenance branch starting in r1.2, commit the fix on this branch and create a release tag r1.3 on the maintenance branch when done (and changed the version to v1.0.1, updated the CHANGELOG etc). If you want to merge it also into main depends of the kind of fix ... it could be a workaround (e.g. some description) which is only valid for v1.0.x, but can only be fixed in v1.1.0 correctly as you don't want to touch the API itself in v1.0.1.