-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release scripts for modules #12452
Release scripts for modules #12452
Conversation
… upstream. Examplar invocations: Edit go.mod files such that all etcd modules are pointing on given version: ``` % DRY_RUN=false TARGET_VERSION="v3.5.13" ./scripts/release_mod.sh update_versions ``` Tag latest commit with current version number for all the modules and push upstream: ``` % DRY_RUN=true REMOTE_REPO="origin" ./scripts/release_mod.sh push_mod_tags ```
8054f47
to
6ea0f1f
Compare
|
5a74ebc
to
d31c0ca
Compare
instead of v3.0.0-000101010000000-00000000000, that might be misleading as we don't develop etcd v3.0.0 any longer. This version is a virtual version and is not supposed to be tagged within the repository. We should tag real versions like: 3.5.0-alpha.0. Please notice that go.etcd.io/etcd/client/v2 will be versioned as `v2.305.0-pre`. The reason is that client v2 must have v2 version. I propose a convention to envode the major version as 100x in minor version to make the association to the underlying repository clear, staying within v2 version family. The change was generated using: ``` DRY_RUN=false TARGET_VERSION="v3.5.0-pre" ./scripts/release_mod.sh update_versions ```
d31c0ca
to
eeafcef
Compare
Could you please review / consider merging. Thank you. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I am not super familiar with the release process. The release was mostly done by @gyuho and sometimes @jpbetz. I believe the script used for previous releases is https://github.com/etcd-io/etcd/blob/master/scripts/release. As I am reading through the existing script, it looks like there are some overlaps between the existing one and the one you are adding. Is it possible to merge the new script into the existing one? (Am I making sense?)
I'm definitely planning to integrate them. Although I think that tar-ball release we will need in O(1 quarter) when we are ready to ship 3.5.0-rc version, so there is some time for doing the integration properly. For now I'm proposing following step-by-step plan:
|
@ptabor Thanks for the great initiatives. Should we create a separate issue to track the release process? |
I think that'd be great. People are eagerly waiting for the release and right now there is not a lot of information about it. |
The issue tracking release: #12498 |
Release: Scripts to change versions in all go.mod files and push tags upstream.
Exemplar invocations:
Editing of go.mod files such that all etcd modules are pointing on given version (e.g. "v3.5.13"):
Tagging latest commit with current version numbers for all the modules and pushing it upstreamt o
origin
:The arbitrary choice I'm proposing in the PR is how we tag versions for module:
This is v2 module stored in the repository and kept in-sync with v3 version hierarchy.
The v2 modules need to have version of v2.x.y . So I'm proposing to version them as
v2.30x.y
(e.g. v2.305.12) when the rest of code is versioned as v3.5.12. This creates very intuitive mapping and is future proof till etcd 3.99.y.