Helm tracks request

Like with the other Kubernetes snaps (Kubernetes 1.18 snap tracks) could we please add 2.14, 2.15, 2.16 tracks for the Helm snap please?

Upgrading from 2.14 to 2.15 has inconvenienced some people https://www.reddit.com/r/Ubuntu/comments/cqoi7i/ive_heard_that_snaps_autoupdate_is_this_correct/f5yedd9/

2.15 is the current stable, 2.16 is the next release and would be great to allow people to try it and then revert.


Helm has no existing tracks and the versioning scheme is different from that of k8s so it seems prudent to do this as a new track request and allow for some time for reviewers to request information and cast votes.

I’m also not sure what the release cadence is or whether it is tied to Kubernetes updates. Can you provide some info about this? (if there’s a document with Helm release schedule and versioning, I’m happy to go in for a read).

  • Daniel

Hi @roadmr It isn’t tied to k8s releases and I don’t think there is a set cadence. However, with major release 3, this is now really important to get out as releasing Helm 3 to the snap store will break everyone.


I could only find isolated tidbits about Helm versioning and cadence:

Also, Helm 2.14 was released on May 15, 2.15 on October 18th, 2.16 on November 3rd, and 3.0.0 tagged on Nov 13th; the docs state that “Minor releases are for new feature additions that do not break backwards compatibility”; definitely looks like a somewhat in-flux development process which I’m not sure lends itself well to tracks (2.x and 3.x would).

That said, if you’re saying people have experienced problems upgrading, that’s usually a criteria for which we do grant tracks, so I’m reluctantly +1 to grant this request.

We still need at least one more vote from @reviewers on this request.

  • Daniel
1 Like

Thanks @roadmr I’m fine with major only as well; but there have been breakages between minor releases in the past. They’re usually fixable, but we end up having to support that.

Indeed: the point of tracks is to serve your needs, not mine; which is why I do agree to have all the tracks to requested even if the release model seems a bit inconsistent. No worries, let’s just wait a few days to see what other reviewers have to say.

  • Daniel

+1 from me - seems like an exemplary use of tracks

+1 from me too. Makes sense.

Not sure what happens next, but could we please start with




We got a total of +3 votes from reviewers and we’re past the waiting period, so I have created the two requested tracks, they are good to go.

Do let me know if you need the other ones (2.14 and 2.15) or they can wait.

  • Daniel
1 Like

To be on the safe side, can I request 2.15?

Hi @hiromi,

In principle yes, sure, but to be on the safe side (hehe), I would like to get @joedborg’s thoughts on that since he was the original requester/driver here.

No worries, if he says it’s OK I’ll create the tracks right away.

  • Daniel
1 Like

Sounds good. Thank you, @roadmr!

Thanks @hiromi and @roadmr, please open the 2.15 track and I’ll try and get some builds there this week.

Thanks ! The 2.15 track is open as well, cheers!

  • Daniel

So, guys. Our Travis build got broken since we unexpectedly got helm 3 installed by the Snap addon:

      - name: helm # Installing Helm
        classic: true

We haven’t expected to get Helm 3… Please advise, to to stick to Helm 2 version?

Interesting - I would have thought the point of having the 3.0 track was to release 3.0 there since Joe stated:

I’m surprised 3.0 was released to latest after having this discussion, but that is the prerogative of the publisher, nothing intrinsically wrong with that.

@vbg-chewy apparently per https://docs.travis-ci.com/user/deployment/snaps/ you can add channel: 2.16/stable to your snap declaration in your travis.yaml, that’ll force using the 2.16 track.

  • Daniel