Using branches on non-stable channels

store
1

Hmm… the store isn’t letting me do this, did I miss part of the spec that said branches can only be made for stable?

$ snapcraft release nextcloud 1399 edge/pr-281
Branch must target stable risk
2

Yes, “branches” can currently be done only for “stable”.

3

Is that part of the design/how we intend branches to work, or just where we are today?

4

This is per design, as it was stated at the end of last year.

In the latest weeks there were talks about allowing branches on any risk, but there’s no formal requirement so far for that.

5

Huh, yeah, my ultimate dream is to have a branch per pull request, but those are definitely not stable. And LP made the choice not to support branches since they were stable-only. So I’m currently pushing to a “test” branch on LP, spinning off builds, downloading them individually, and running snapcraft push <snap> --release=stable/pr-X by hand. Not the easiest path.

6

Can’t see a good reason to forbid using branches on non-stable channels, even more considering they are naturally temporary. Feels like a good way to offer people a chance to test experimental features still under development.

1 Like
7

Agreed, and we had discussed at the sprint to open this up but that work just didn’t happen yet.

1 Like
8

If we allow branches for non-stable risk, the situation of “same branch name in the same track” appears, example:

stable/hotfix1
candidate/hotfix1

or

3.4/stable/fix
3.4/edge/fix

IIUC, we wanted to forbid the same branch name inside the same track (which was something natural if we had branches only for stable), but now we must confirm that restriction, or not.

So, are these cases (like the shown in the examples) valid ones, or we want to forbid the same name for branches inside the same track?

Thanks!

9

I think those are valid uses and channel is really the unique tuple of (track, risk, branch).

10

Yeah, I brought this up as the first thing I tried out with a branch was to release a build that came out of a PR to iterate on, the thought of using edge was the first thing that came to mind as even if the PR landed it would also release to edge itself.

PS: looking at the date, I don’t know how I missed this conversation.

11

As Bret points out, a channel is really formed by the tuple (track, risk, branch), where the branch is optional and track defaults to latest, per our agreements and the documentation.

As such, there’s nothing wrong in having:

  • multiple risks and same track: 1.0/stable + 1.0/candidate
  • multiple tracks and same risk: 1.0/stable + 2.0/stable
  • multiple risks and same branch: stable/fix-one + beta/fix-one
  • multiple branches and same risk: stable/fix-one + stable/fix-two

and so on.