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.

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?

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

@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.