Investigate post-beta release approach

[eak13]

Need to investigate and propose an approach for releasing airship 2.0 code post-beta release.

• Including treatment of images and code
• Including cross-airship-project versioning
• Including release note strategy

Can possibly look at what cluster-api does for their releases:

• https://github.com/kubernetes-sigs/cluster-api/releases
• Generated from: https://github.com/kubernetes-sigs/cluster-api/blob/master/hack/tools/release/notes.go
• Generated via: https://github.com/kubernetes-sigs/cluster-api/blob/master/Makefile#L172-L173

[seaneagan]

Ideally we wouldn't have to maintain our own release notes generation code etc, here is an example:

https://github.com/fluxcd/toolkit/blob/master/.github/workflows/release.yaml

[seaneagan]

It looks like the github bot is not working, here is the implementation for release notes generation:
https://review.opendev.org/#/c/762714/

Next steps for the release workflow would be:

1. image tagging, which would require adding an encrypted secret for the quay credentials to the airshipctl github repo: https://docs.github.com/en/free-pro-team@latest/actions/reference/encrypted-secrets
   We could also consider switching to github container registry which has some advantages.
2. publish go binaries for airshipctl using something like http://goreleaser.com?
3. publish documentation for the release?

[teoyaomiqui]

@seaneagan this looks nice. I see that this release has all the issues we had since the start? Will next releases contain only delta issues?

[seaneagan]

@teoyaomiqui yes, it will diff against the previous tag when one exists

[airshipbot]

A [Related Change](https://review.opendev.org/762714 was merged. This issue may be ready to close.

[seaneagan]

Here are the instructions on how to create a tag:

https://docs.opendev.org/opendev/infra-manual/latest/drivers.html#tagging-a-release

You need to be in this group to have permissions to push the tag:

https://review.opendev.org/admin/groups/1914,members

Once the related automation patchsets all merge, I will create a v2.0.0-beta.2 tag to test the whole flow.

[airshipbot]

Related Change #780940

Subject: Fix calculation of previous tag for release notes gen
Link: https://review.opendev.org/c/airship/airshipctl/+/780940
Status: MERGED
Owner: Sean Eagan (sean.eagan@att.com)

Approvals

Code-Review
+2 Kostyantyn Kalynovskyi
+2 Drew Walters
Verified
+1 ATT Airship2.0 CI
+2 Zuul
Workflow
+1 Drew Walters

Last Updated: 2021-03-17 12:59:03 CDT

[seaneagan]

Semver release automation is almost complete for airshipctl and krm functions, everything in the this (airshipctl) repo.

Open questions:

1. Do we want to commit to a strict semver policy? e.g. any document set that works with airshipctl v1.0.0 should work up to the release preceding airshipctl v2.0.0.

Not yet at least. Would like to work toward airshipctl CLI stability, manifest stability will be more difficult.

2. Which other airship repos do we want to implement this semver release automation for?

yes for treasuremap, images, charts, HCO, others?

3. Just to confirm, each tool should have its own fully independent semantic versioning / branching?

We want to try to branch each repo in sync with each other

4. Where to start version numbers at? Semver would seem to dictate treasuremap should start at 2.0.0 since it already has an existing 1.x (part of "Airship 1"). Everything else (airshipctl, krm functions, hco, ...) have not yet had a 1.0.0 so if following semver they would start at 1.0.0 (or 0.1.0 for anything deemed still in "initial development").

We want to start everything at 2.0.0

Edit: These were discussed in the 3/23 design call, notes added above

[seaneagan]

The release automation flow for:

1. release notes
2. quay image tagging
3. binary publishing (airshipctl only)

is complete for everything in this repo (airshipctl, krm functions). Let's open github issues for any other repos (see above) that we want this automation in.

In the 3/23 design call i think we landed on the following release process:

Minor release (v2.x.0)

1. push matching semver format release tags across all repos (besides treasuremap) v2.x.0
2. create branch v2.x in treasuremap
3. pin to initial versions from 1. in branch from 2., and tag with v2.x.0

Patch release (v2.x.y)

1. Create patch versions for any projects needed e.g. airshipctl v2.x.y
2. Pin to these in treasuremap minor branch v2.x
3. Tag treasuremap minor branch with patch version v2.x.y

Assumption is we can do on-demand branching for sub-projects (when patches are needed).
For treasuremap we need to branch as part of initial minor release, since main will be pinning to commits of sub-projects, rather than to semver tags.

[seaneagan]

Closing per above comment.