More restrictive branch names proposal

store
1

We have snap ‘channel’ branches documented, but we provide little guidance on the restrictions currently imposed in their actual names.

The Store enforces lowercase letters with dashes or dots as separators and since the branch creation is implicit when releasing, publishers get an error when their proposed branch name doesn’t comply:

$ snapcraft release surl 307 stable/foo+bar
invalid-field: Invalid branch name: foo+bar. Enter a value consisting of letters, numbers or hyphens. Hyphens cannot occur at the start or end of the chosen value.

Alert: the error message is incomplete, DOTs are currently allowed

I would like to propose more restrictive branch names going forward, particularly dropping support for DOTs, which is already overused in many other places representing namespaces or subdomains and all sorts of abstractions. That does not fit into a snap branch name.

Refusing DOTs will prevent branches named after versions e.g. stable/1.2.3-1, which would be better represented by a 1.2 track, if necessary, and a purpose-drive branch name hotfix-memory-leak or bug-1234; something the resembles the time-limit and specific purpose essence of a snap branch. Naming branches after a specific version gives users the impression they will live forever, when they clearly won’t (remember they auto-expire)

Refusing DOTs will also prevent branches named after ubuntu releases, e.g. stable/18.04, which also gives a misleading sense of living as long as the corresponding release.

There is a considerable number of existing branches in use (clients tracking them) that will continue to be available and ‘extendable’ as long as the publishers need them, but I propose that we no longer allow DOTs for new branches.

Additionally, I would also like to prevent common meaningless patterns, as:

  • Only digits (123 or 666)
  • Only digits and dashes (1-2 or 12-34)
  • Less than 3 characters
  • Longer than 32 characters

Any comments or particular cases the proposed restriction would cause problems ?

2

Every snap seeded on an ubuntu image has a stable/ubuntu-XX.YY branch. We’ll need a different plan for those if you do this.

1 Like
3

I don’t think the reasons stated are strong enough to justify the change in behavior. To @mwhudson’s point, when you start tracking a branch, even if the snap released there only lives for 30 days, the branch lives on and is still tracked. The branch may end up inheriting from stable (or whatever the risk is) after 30 days of no release, but as soon as a new revision is released in the branch anyone tracking it still gets it. Has that behavior changed? If not we’d also need to create a way to automatically switch the branch being tracked, which sounds kinda gross. Also consider all the auto-builds/auto-releases happening in CI that would break.

4

@kyrofa an auto-expired branch must live as long as there are clients tracking it, in theory, they could be safely removed once there is no more active installed base.
Anyway, trying to restrict names once they are already in use is an inglorious battle.

@mwhudson you are right, there are several branches named after ubuntu releases. Before suggesting the simple name fixing (s/./-/g) in our workflows, we should probably dig a bit more to understand why we are using branches in the first place. Is it a temporary measure for building the images or the images are actually tracking these branches while they live ? If it’s the latter, these branches would require period releases to not auto-expire.

5

@cprov the rationale behind the branches is explained in https://wiki.ubuntu.com/UbuntuSeededSnaps

Snaps included in images will be installed referencing a per-Ubuntu-series branch following the name format ubuntu-$version (e.g.: ubuntu-16.04). This ensures forwards-compatibility by allowing publishing to this branch if the mainline of a snap becomes incompatible with a given Ubuntu release, without requiring up-front maintenance of multiple snap channels.

1 Like
6

Yup, thanks for the reference. Images are effectively tracking empty branches, with expressive installed base, as planned.

It’s hard to ask everyone else to stop using DOTs if we already use them that heavily. We can certainly find a middle-ground restriction (size, deny only digit-and-separator), but there seems to be no way to abolish the dotted notation.