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
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 and dashes(
Less than 3 characters
Longer than 32 characters
Any comments or particular cases the proposed restriction would cause problems ?