Improvements to branch/release workflow

[edmorley]

Hi!

There have been several occasions when fixes have been applied to one branch but not others:

• priorityClassName change missing from some releases/branches #834
• Release v1.5.2 #574 (comment)
• possibly Issue #282 regression in master -- Pods stuck in ContainerCreating if created/delete while the aws-node on the same instance is (re)deploying #601

I've also found the current branch/tag/versioning approach confusing when upgrading versions, since I never know whether to use the example Calico/CNI manifests from master, a version branch, or the git tag. If I pick the wrong one, then there's the risk of missing fixes due to the inconsistency mentioned above.

Would it be possible to:

• change branch usage so that there's only one branch per minor release (eg release-1.5.x instead of release-1.5.1, release-1.5.2) -- since the branches are mostly redundant given the version tags
• add automation/process to ensure that master is kept in sync with the release-1.N.x branches -- or else come up with a way that means the duplication between them isn't required? (eg all development happens on master, apart from specific cherry-pick branches; then version tags are used as the canonical way to refer to a release).

[jaypipes]

Related: #758, #685, #687

[jaypipes]

Hi @edmorley! Thanks for raising this issue. It's something we're keenly aware of and we acknowledge the existing state of affairs is far from optimal.

We are currently having a discussion internally on how to reduce the duplication of configuration files (not just for the CNI repo) between the source project repo and the eks-charts repo. We've also discussed (specifically in regards to this CNI repo) getting rid of the versioned config directories (e.g. config/v1.5 and instead having a single config/ directory containing the configuration files and using git (properly) where the configuration files in the config/ directory will be for the specific git tag/branch.

[mogren]

@edmorley We have finally gotten around to do this. Changes implemented:

• All PRs merge to master branch first (Except changelog and config for release candidates)
• Only branch for Minor versions, the release-1.7 has both v1.7.0 and v1.7.1
• Config files are generated by a jsonnet script, making them consistent for each release.