-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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 etcd 3.5.0-alpha.0 #12498
Comments
Is there an ETA for this alpha release? |
This needs to be executed by a maintainer (usually @gyuho). |
Would it make sense to tag a new v2 client version with this release (or rather together with 3.5)? Or maybe it can be tagged sooner? |
The provided scripts would tag them as v2.305.0-alpha.0 automatically: |
Cool! We just have to wait for a tag then. :) |
waiting for a v3.5 tag to use new client |
Any updates on tagging 3.5.0? We'd like to start integrating an etcd client into our setup as soon as possible. |
yep, it becomes uncomfortable because I cannot interact with my generated files with newest grpc version |
Temporary workaround:
Waiting for |
This workaround works great for applications, but replaces are not propagated from libraries, so |
Currently there are still open issues / PRs which are tagged to milestone v3.5. They need to either be closed or moved to a later release. Before releasing v3.4, we should also try to fix as much flaky tests as possible (which @ptabor has fixed a lot!). Before releasing v3.4, we also had some benchmarks, both on etcd itself, and with its major user kubernetes. For reference: #10943 |
I'm rooting for moving them to a later release at this point 🙂 |
I would not think about release of this alpha.0 as a request to start full release-3.5 train. It's common for many projects to have many alphas that have different sets of features to get early feedback on them Please don't interpret this post as opposing to cut 3.5 earlier as I support release-often, release-early paradigm. I'm just suggesting that the release of 3.5.0-alpha.0 should IMHO be orthogonal to decision whether we consider this release feature-complete-enough or not-yet. |
@ptabor Sorry for being the blocker. I would really like to add more people in our release process (really nothing fancy we need here, just write access to the repository). What do you think @jpbetz? @ptabor Do we have a list of pending changes to make this happen? I will find sometime this and next week to prioritize. |
I believe most people here are talking not about 3.5 release specifically, but instead the first release that can be explicitly referenced in go.mod instead of relying on dates/commits. IE: if there was a possibility to release 3.4 with proper go modules - most people would be fine with that. |
Given how long the community has been waiting for module support (no blame, just stating a fact), I'd prioritize that and delay other features to a next version (especially since many issues are still labeled as investigating). But I agree that's a different topic than releasing an alpha to start testing the module support. BTW, testing module support was already possible with a few workarounds mentioned above and I've been playing with them a lot (mostly the clients). So I wouldn't expect an alpha release to add much to the testing capabilities. Libraries probably still won't upgrade to alpha versions. |
#12497 - got submitted. Thank you @jingyih . I was playing with the release script today, to make sure it's safe.
(overridden repository for speed, safety & local changes). That's the full output: https://termbin.com/vua6 The most important commands the scripts execute on repo (I appreciate second look): Committs:
as
Creates and pushes tags:
Tarballs are getting created:
I'm not able to build dockers due to my operating-system.
But there were no changes. |
@gyuho: I think there are following decisions to make:
|
Hi, just following up to see if there are any updates here. Trying to update the etcd client in terraform and it's blocked on this change. hashicorp/terraform#25554 |
I plan to finalize #12652 (grpc-1.32 - that is code complete) and make experimental 3.5.0-alpha.0 release. @gyuho Please go over the questions 1-3 from: #12498 (comment) |
Any updates about the alpha release? @gyuho ? |
+1 to onboarding additional maintainers for release. @ptabor certainly knows his way around the related systems, so I feel he should have privileges. Anyone else we should involve @ptabor? |
I'm in favor of this.
I agree that we should wait until we've eliminated any major known issues on master before branching.
alpha tags look right to me
We've been signing with the same personal GPG private keys that we've registered with github so that anything we sign on github with them is marked as 'verified'. |
Apologies for late response! Pinned the issue for better visibility.
Yes, as @jpbetz said.
I don't see any major blocker other than auto learner promote? @jingyih Could you confirm or should we block?
+1 to alpha
Yes, you can use your own "registered" private key, but in the spirit of automated release going forward, I wouldn't mind tagging without any signature. What do you think @jpbetz? I think providing sha digests for release artifacts are good enough. |
I performed the 3.5.0-alpha.0 release process. The draft of release note is here (to be published): https://github.com/etcd-io/etcd/releases/tag/untagged-58083814dada3f07f4e5 Sanity check:
PASSED |
Thanks, I'll update my draft PRs. |
Let's pre-release etcd 3.5.0 branch, e.g. as 3.5.0-alpha.0
Goals
This will allow:
Why 3.5.0-alpha.0 ?
It's 3.5.0-alpha.0 < 3.5.0-alpha.1 < 3.5.0-beta.0 < 3.5.0-c.0< 3.5.0-dev.0 < 3.5.0-pre.0
Shell we create branch "release-3.5" before releasing etcd-3.5.0-alpha.0 ?
I would softly suggest not for following reasons:
git describe
is able to self-identify and name the current state of the repo. On kubernetes it returnsv1.20.0-beta.2-86-g5ed4b76a03b
. Currently on etcd master branch it returns:v3.3.0-rc.0-3744-g28d1af294
that is pretty misleading.How:
Modularized release script integration #12497 the following command should do the trick:
@gyuho
The text was updated successfully, but these errors were encountered: