What's the plan for version 3.5? When will it be released?

[Jayden-onl]

As we know, the package management of recent versions is not good.
The version of grpc also old.
When will version 3.5 be released?
😂

[mlboy]

+1

[dmitris]

there's a little bit of discussion of 3.5 in https://www.youtube.com/watch?v=SqfxU9DhBOc&feature=youtu.be

Maybe it would be possible to create something like Release-3.5 or Milestone-3.5 label to group the related issues and to give a bit more visibility on what's still in flight, where help could be needed (ex. with testing) etc.?

/cc @gyuho

[mlboy]

The label has created which is named "area/clientv3", And milestone is "etcd-v3.5".
But, I anxiously hope that put it on schedule.

[sagikazarmark]

There is a milestone for 3.5: https://github.com/etcd-io/etcd/milestone/37

A lot of issues are still labeled as "Investigating" though.

[sagikazarmark]

Let's say 3.5-alpha gets released soonish (#12498). What does that mean for the stable 3.5 release?

As I mentioned in the linked issue, half the world depends on etcd (either directly or transitively) and libraries probably won't upgrade to an alpha version, so the situation won't be resolved with an alpha release. It'll probably be a great demonstration of the release script, though.

So the question is: what comes after the alpha version?

As far as I can see, there is a gRPC upgrade issue that's also close to being resolved. Is there anything else that blocks a stable version other than an alpha testing period? If not, would it be possible to set a deadline for the alpha testing period and (if nothing comes up) just tag a release when that deadline is over?

WDYT @ptabor @gyuho ?

If not, what's the timeline that we can expect? I imagine there are a lot of parties to coordinate with (Kubernetes being a prominent one), but etcd 3.5 has been stalled enough despite bringing the (IMHO) most important improvement for ecosystem in a long time, so it'd be really great if you could shed some light on the future of etcd 3.5.

Thanks a lot for the hard work you are doing!

[ptabor]

I'm all for releasing (and getting feedback) frequently.
Looking at the list https://github.com/etcd-io/etcd/milestone/37 I think most of this issues are 2017-2018 and looks like carry-over.

@maxenglander owns the most-recent issues (auto-promoting nodes). Do you plan to work on them ?

Personally 3.5-stable I would scope to:

• P0 Finish the grpc stuff
• P1 Reduce etcd dependency on store v2 #12800 make sure v2-store can be opted-out to unblock perf-gains & decomissioning this code in 3.6.
• (optional) P2 subsplit proxy code to separate module (opt-in binary)
• (optional) P2 subsplit etcdadm code to separate module (opt-in binary)
• (optional) Move big parts of clientv3/server code to 'internal' subdir [such its known what's implementation detail]
  But also fine with calling a release calendar for early Q2 and taking whatever is on time.

[maxenglander]

Hey @ptabor I would like to continue working on auto-promoting nodes. I have a proof-of-concept implementation (#10887), but I am waiting for a review of etcd-io/website#107 (migrated from #10913) before going further. Thanks!

[sagikazarmark]

Checking in to see if there is an update on a 3.5 release date.

I've updated etcd in Dex, Viper and go-kit (in Draft PRs) and they seem to be working as expected (go modules work, e2e tests passed).

[sagikazarmark]

The community meeting notes mention "Mid May" as a rough timeline / feature-freeze timeline. What does that mean exactly? Is that an estimated release date? Or is it just a target for feature freeze and release will happen somewhere in the future following that?

[gyuho]

We have quite a few milestones left https://github.com/etcd-io/etcd/issues?q=is%3Aopen+is%3Aissue+milestone%3Aetcd-v3.5

• *: define strict TLS 1.2 cipher suite default #10304
• Support client configuration via environmental variables #12785
• Use Go 1.16 for 3.5 release and testing #12732

[liggitt]

I'm also interested in this, since v3.5.0 unblocks grpc dependency upgrades (xref kubernetes/kubernetes#100488)

[liggitt]

From the perspective of a client library consumer, go1.16 is the only open item I see in the milestone that seems necessary to resolve.

The other issues in the milestone are either long-standing escapees from previous releases or don't look regressions (e.g. the regression part of #12785 was resolved in #12786)

P1 make sure v2-store can be opted-out to unblock perf-gains & decomissioning this code in 3.6.

Is there an open issue tracking that?

[ptabor]

On the last community meeting we discussed this and taking in consideration the GKE needs, in particular release of 1.22 in June/July, the decision was around this line:

• freeze 1.15 mid May, i.e. release etcd-3.5.0-beta.1 and start accepting only bugfixes to the release.
• consider this as a motivation for doing from the milestone list as much as possible - for the items that do have contributors/sponsorship to really get done. The remaining items can be moved to next milestones, as they used to be.

@gyuho: you were not present, so please let us know if you are OK with this.

I think that 3.5 release is pretty special because of the packages rename, so formally its the only time (before v4)
where we can perform bigger code-reorganizations, following (or breaking 'once') the golang compatibility-promise.
It's a significant opportunity to do cleanups, that are not urgent from functional perspective - but now or not at all.

[ptabor]

P1 make sure v2-store can be opted-out to unblock perf-gains & decomissioning this code in 3.6.

Is there an open issue tracking that?

#12800

[gyuho]

freeze 1.15 mid May, i.e. release etcd-3.5.0-beta.1 and start accepting only bugfixes to the release.

Mid-May sounds reasonable. Thanks for the update. This will help us prioritize.

[cdyue]

Mid-May sounds reasonable. Thanks for the update. This will help us prioritize.

Maybe 2022 Mid-May.

[lilic]

@ptabor For the not completed checkpoints on your list in this #12330 (comment) are you looking for folks who want to contribute? As I am happy to take over some of the work, thank you!

[ptabor]

Thank you @lilic for your offer. I'm doing (slower then expected) progress on storeV2.

Out of my list, I have nothing in progress a.d.
(optional) P2 subsplit proxy code to separate module (opt-in binary)
With the goal to separate binary with not that active development/support from the core etcd server,
so if you have free-cycles and think its worthwhile, I will appreciate.

Thank you,
Piotr

[ptabor]

May 17th is still the date for 3.5 feature freeze.

[lilic]

I am favouring removing Prometheus global registry (or at least trying to), in favour of the "P2 subsplit proxy code to separate module (opt-in binary)", hope that is okay @ptabor, if you don't get it to in the next release still happy to take that one on!

I noticed we still have a few PRs open with 3.5 nice to have. Should we ping the folks again on the PRs, wdyt? https://github.com/etcd-io/etcd/labels/rel%2F3.5-nice-to-have

[lilic]

#12970 just linking this here.