Juju snap tracks and channels

juju
1

latest track

  • latest/stable - currently the 2.4 stable release updated each time we release a new 2.4
  • latest/candidate - what we expect will become the next 2.5.x release. This is used for QA solutions testing and folks validating the release.
  • latest/beta - currently the home of 2.5 betas
  • latest/edge - updated per commit landed against develop. This is the “daily” build of trunk and is currently the work in progress for 2.6

2.5 track

  • 2.5/stable - will be the latest stable of 2.4. This will also track the latest/stable as 2. is the latest release.
  • 2.5/candidate - what we expect will become the next 2.4.x release. This is used for QA solutions testing and folks validating the release. Currently this would be for when we deem 2.4.1 ready for release.
  • 2.5/beta - as 2.4 is out we’d not use the beta channel
  • 2.5/edge - updated per commit landed against the 2.4 branch. This is the “daily” as we go from one 2.4 release to the next.

2.4 track

  • 2.4/stable - the latest stable of 2.4. This will also track the latest/stable as 2.4 is the latest release.
  • 2.4/candidate - what we expect will become the next 2.4.x release. This is used for QA solutions testing and folks validating the release. Currently this would be for when we deem 2.4.1 ready for release.
  • 2.4/beta - as 2.4 is out we’d not use the beta channel
  • 2.4/edge - updated per commit landed against the 2.4 branch. This is the “daily” as we go from one 2.4 release to the next.

2.3 track

  • 2.3/stable - latest stable release of 2.3.x
  • 2.3/candidate - what we expect will become the next 2.3.x release. This is used for QA solutions testing and folks validating the release.
  • 2.3/beta - not used as 2.3 has been released and so beta users would just get candidate releases
  • 2.3/edge - updated per commit landed against the 2.3 branch. This is the “daily” as we go from one 2.3 release to the next.
2 Likes
2

Sounds like a good layout and use of the various channels.

3

The channels for 2.3 and 2.4 are now open. I’ve released the last stable release to each so we now have

  • 2.4/stable at 2.4.0
  • 2.3/stable at 2.3.8

We can now begin to work on automating the builds into the release processes we need from here.

You can see the tracks listed out here: https://snapcraft.io/juju

4

beta is currently 2.4-rc3 (and as @thumper points out, behind candidate and stable).

With the new tracks, should we then points 2.4/edge|beta|candidate point to the 2.4.1-* builds?
Where should beta then point? at edge? (i.e. 2.5-beta1-).

Seems like we’re in an awkward time with versions and tracks :slight_smile:

5

Yes, the next steps from here are pointing the various builds at the track/channels now that they exist.

I would think that we’ll need to update the various build jobs to handle comitting to the git repos when they need to with the info for each track we have going? Can we keep the single edge job, for instance, but have it pushed whenever a 2.3 branch, 2.4branch, or develop are merged to?

6

To clarify; the setup for which track gets built into (and how the snap is actually built) is done on the Launchpad end.
All that job does is update a git repo containing the build snapcraft.yaml and pushes it, LP monitors that and builds on new commits.

To answer your question;
We should be able to make a couple of jobs (we can template it in our JJB, so very little extra bits needed) to push to different branches and have the snap builds handled by LP.

I’m not 100% sure how the LP snap builds are setup, but I’m sure it’s not a biggie

7

FYI, the 2.4/stable is currently still sitting at 2.4.0 while stable is 2.4.1.

zeestrat@vagrant:~/dev$ snap info juju
name:      juju
summary:   juju client
publisher: canonical
contact:   http://jujucharms.com
license:   unknown
description: |
  Through the use of charms, juju provides you with shareable, re-usable, and repeatable expressions
  of devops best practices.
commands:
  - juju
snap-id:      e2CPHpB1fUxcKtCyJTsm5t3hN9axJ0yj
tracking:     stable
refresh-date: today at 07:36 UTC
channels:
  stable:        2.4.1                     (4768) 55MB classic
  candidate:     2.4.2+2.4-b866365         (4812) 63MB classic
  beta:          2.4-rc3                   (4583) 55MB classic
  edge:          2.5-beta1+develop-6e24852 (4816) 66MB classic
  2.3/stable:    2.3.8                     (4423) 55MB classic
  2.3/candidate: ↑
  2.3/beta:      ↑
  2.3/edge:      ↑
  2.4/stable:    2.4.0                     (4587) 55MB classic
  2.4/candidate: 2.4.1+2.4-9181c94         (4700) 63MB classic
  2.4/beta:      ↑
  2.4/edge:      ↑
installed:       2.4.1                     (4768) 55MB classic
8

@szeestraten I’m currently working on this. While we’ve got the tracks setup it’s manual and I haven’t updated the various release tooling and documentation/checklists yet so that it’s perfect. I’ll have it updated in a few here. Apologies while we smooth out the rough edges of the new setup.

9

Heads up that Heather got working the 2.4 branch builds going into the 2.4/edge channel. With that done I’ve closed the latest/candidate channel which will be the home of 2.5-rc1 once it’s available.

If you’re looking to test out the latest in the 2.4 commits make sure to use the 2.4/edge.

1 Like
10

Note there’s now a 2.5 track populated with an edge snap for each commit to the 2.5 branch of code.

Once we release 2.5 GA it’ll be the latest/stable and there will be no beta/candidate. latest/edge will be the ongoing work for 2.6.

If you’re looking for the latest stable work it’ll very soon be in the 2.5 track.