Branching Strategy for Nephio releases

[gvbalaji]

Currently we have a single "main" branch and during the release time we tag the releases. But this has multiple issues:

Catalog repo issues

• Our "catalog" repo contents are relase dependent. We need to change the tag of the packages in the catalog repo to the release tag version when we cut the release.
• After the release is cut we need to change the contents back to the "main" so that ongoing development can go on.

Other life cycle management issues

• If we have to make a patch release (z stream ) for a given release say R2 simply tagging the release will not work.
• Same case with hot fixes or if we need to cherry pick something such as security fix.

Hence the best way forward is to have a branching strategy for the releases.

There were two options for branching that we discussed

1. Branch per release
2. Stable and Development branch

Branch per release

• A branch will be cut when we do a release.
• This is generally used and straight forward.
• Catalog repo changes only apply to the branch
• Patch releases are done using the branch.
• Fixes such as security fixes and individual commits as needed are cherry picked into the branch.
• Helps us if we have a multi release support strategy
• There is some concern on multiple branches being in the repo but we also discussed, branches are cheap and having many of them is not a big deal.

Stable Branch

• There will be one stable branch for releases and one main branch for development
• This will solve some of the issues such as catalog repo.
• This strategy will still have issues for patching and multi release support

Based on the above probably having "Branch per release" is the most straightforward implementation and I am leaning towards that. Please add your thoughts in this discussion.

References
https://w1.fi/releases.html
https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases

[henderiw]

We should distinguish Catalog from the rest of the repo's.
In catalog I would advocate to have a branch per package or even per revision with a tag, it eases a lot of dependencies we have.

For the other repo's I suggest a branch close to the release which we use to maintain once a release is cut, or we create it when we cut it and this serves the basis to fix issues when they arise. This removes a lot of overhead of creating and maintaining code in various places.

[henderiw]

on catalog you have basically 3 options:

1. like we do today. All get merged in main with directories (required for porch), any tag you put will tag all files, files related to the package or not related to the package. Pro: 1 branch, Con:
2. create a branch per package. Pro: clear separation, Con: for a change on multiple packages -> you need to do x updates.
3. create a repo per package. Pro: clear separation, Con: for a change on multiple packages -> you need to do x updates.

The down side of 2 and 3 could also be seen as a good thing as you should not update things across package, anyhow the tag has to be per package. So no matter how you cut it you have to do X things,

[electrocucaracha]

One benefit of the option 3 is that we can rely on the vendor package. E.g. Multus could provide a multus kpt package and having their own release cycle and once in a while we can upgrade our references.

[henderiw]

this would be ideal if kit would have been accepted as a solution by the industry but I believe this is not what we see. I am of the opinion that artefacts should be consumable ideally from these repos, but there will always be things we manage by ourselves
as well. Lets keep this in mind.

[electrocucaracha]

Another points to consider for the branching strategy of the catalog are:

• Tooling - Whatever strategy that we choose here it needs to be easy to setup an automation process that creates tags, branches, git submodules, etc.
• Testing/Validation - Changes on packages needs to be tested in the CI prior merging.
• Industry reference - The structure and stragegy used will be follow by the industry as reference, so they have to provide realistic scenarios.

[tliron]

Question:

Do we really need separate versions per package? There could be a simple solution of having all our packages have the same version, which is tied to the Nephio release. It does mean that some packages would get a version bump even if they don't need it, but -- so what? It won't hurt anything (that I can think of).

The big advantage is that we don't have to deal with any of these complications. We treat the catalog as just a normal repo, the same as other Nephio repos. It would also simply things for users, where they simply use the Nephio version and don't have to think about individual package versions.

[electrocucaracha]

Having a single version per package brings a lot of simplicity to the release management, but it doesn't allow upgrading packages separately, or a single change in one package will require to bump the version for the entire repository. Packages have different release cycles which don't necessary align to Nephio release cycle.

[henderiw]

in my view each package has its own lifecycle and we should manage it like this rather than putting a big sticker on it. This is how SW is managed at large and making I big dependency created huge bottlenecks. The success of a distributed system is based on this principle.

[electrocucaracha]

Another point to consider is NF vendors have their own release cycle. So, validation programs are created to avoid any dependency hell

[gvbalaji]

In sig-release meeting we decided we will go with a branch per release. However we will continue with the special branching strategy for catalog .

[gvbalaji]

@radoslawc please add your points and details about using github sub-modules to this discussion.