Yiyiyimu opened a new issue #3726:
URL: https://github.com/apache/apisix/issues/3726
Currently in apisix/apisix-dashboard/apisix-ingress-controller, we have
three different types of branch/tag naming format. Let's say for version 1.0:
| repo | branch | tag | notes |
| ------------------ | ------ | ----- | ----------------------------------- |
| apisix | v1.0 | 1.0 | tags before 1.0 are in format `1.0` |
| dashboard | v1.0 | v1.0 | branch and tag name is the same |
| ingress-controller | v1.0.0 | 1.0.0 | |
There are three main problems for releasing:
1. Since we don't maintain LTS version, we could directly remove all
branches that have been released.
When at release window, maintainers are suggested to use the format
`release/1.0` to create release branch and trigger corresponding release
Actions. The reason for using `release/1.0` is to avoid trigger release Actions
in branch like `verbose` since we tell the release branch by its prefix.
2. Since all releases and related tools are based on tags, we have no
choices but to keep the different format of tags in different repos, which the
universal tools should adapt to. A suggestion is we should define a new tag
format rule for future projects related to apisix, so we won't deal with more
kinds of formats 🤣
3. Currently in apisix, we kind of add tag/make release on random commit
during the release.
- 2.3 tag on the last commit before merging some master commits in
release PR.
[tag](https://github.com/apache/apisix/commit/63f779aeae7a4cfdc3baa5c6dad955ef139719f8),
[PR](https://github.com/apache/apisix/pull/3466)
- 2.2 tag on the last commit of the release PR.
[tag](https://github.com/apache/apisix/commit/e8dcf3793ca40b30047406ac51a79a500356f67b),
[PR](https://github.com/apache/apisix/pull/3168)
- 2.1 tag on the first (force-pushed) commit of the PR.
[tag](https://github.com/apache/apisix/commit/c0f3f73842ca64b92c41c59352d3f9b7969ca738),
[PR](https://github.com/apache/apisix/pull/2887)
- 1.5 tag on the first commit of old release branch but not on release
PR.
[tag](https://github.com/apache/apisix/commit/6c5b52e93ea522009355643feb9d8c5a84e4baf4),
[PR](https://github.com/apache/apisix/pull/1965)
Some references:
- Kong tag on the last commit in release PR, see
[tag](https://github.com/kong/kong/tree/2.3.2)
- Envoy tag on the release PR, see
[tag](https://github.com/envoyproxy/envoy/tree/v1.17.0)
- Skywalking tag on the last commit before new change for next version
the release PR, see [tag](https://github.com/apache/skywalking/tree/v8.3.0)
- Kubernetes tag directly on release branch, and retag for each minor
version, see
[tag](https://github.com/kubernetes/kubernetes/commits/release-1.20)
I think it might be better if we tag the release PR commit, in another
word we add tag right after the release PR got merged, so we won't miss any
commits. If something is missing and we need another round of voting, we create
another PR on the original branch. After the vote passed and new release got
published, we then delete the release branch.
TODO:
- [ ] Change release guide on apisix website, so new release could follow
the new pattern.
- [ ] Delete branches. Change release guide so maintainers need to delete
branch when the release got ended.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
