Track request for etcd 3.2

store
1

Upstream just tagged etcd 3.2.0-rc.0 and I would rather drop releases in a 3.2 track than into latest/edge. Thanks!

2

Hello,

This is done, the track has been created and I also added a simple regex (“guardrail”) so only versions matching this pattern can be released to the track:

^3\.2.*$

Please let me know if anything else is needed,

  • Daniel
3

Thanks Daniel, that’s confirmed as working. And thanks for the guardrails!

Mark

4

@sabdfl Is 3.2 a longstanding major version, or should the track be “3” instead?

5

The upstream tends to maintain overlapping minor versions, so I think a
track is appropriate. I have seen them putting out simultaneous point
releases for 2.3.x, 3.0.x and 3.1.x for example, so I think we need to
be able to support that.

At some stage, we will want to be able to flag a track as obsolete, but
let’s not worry too much about that for now.

Mark

6

That’s the case for pretty much every software with a relevant user base. Patch releases go out while a different minor is being worked on, which from time to time will overlap with another major being released. We need to define what the general pattern that should be established is. We already had a very similar conversation around Docker just a few days ago, for example.

I’ve scheduled a conversation for us here at the sprint to discuss this, and will update this topic with details of the outcome soon.

7

Hello Gustavo,

Was this finally discussed in the sprint? What was the outcome?

Thanks,
Ara.

8

Yes, we had a session on this and agreed to open up tracks for use with minor versions, assuming the project is following something similar to semantic versioning. In other words, if the project has a minor release 3.2 and may offer patch/micro releases such as 3.2.1 under it, we’ll accept tracks for that purpose and include a respective regular expression to guardrail its versions under said track.

I’ve also provided more comprehensive documentation about channel terminology and policy here in the forum.

9

I think the key questions are:

  • is there a stable branch for that proposed track, on which commits
    can be expected
  • will that be mapped to an edge channel for that track for CI builds
  • will that overlap materially in time with other active stable branches

In the semantic versioning case, it is well understood that x.y is a
stable minor version on which point releases x.y.z can be made, where
those point releases are safe automatic upgrades. If the project is thus
following semantic versioning, has stable branches for the minor
versions (x.y, and maintains those minor versions for an extended and
overlapping period, then a track request would be considered favourably.

Mark

1 Like
10

As we discussed in the sprint (and you agreed), with git and similar tools branches and commits can be added once the need arises, so we cannot use that as a deciding factor to provide a track or not. The best we can do is inform people what the purpose of tracks is, and accept their acknowledgement and intention to proceed.

11

Yes, agreed, but we should still signal our expected behavior, which is
edge channels from CI for tracks.