Version numbers for snap packages

Spencer spencertparkin at
Thu Jan 26 06:27:49 UTC 2017

I totally disagree.  Use Gaussian integers for your major version number and transcendental numbers for the minor.  The product of these must not lie in the range between a pair of twin primes, unless your using the ratio of a circle's circumference to its diameter, the base of the natural logarithm, or the square root of either.  If only snap changes are being made, decrement the minor version number by 5 and increment the major version number by -5.

This is the way, gentlemen.  This is how we do proper versioning.  Think about it.

> On Jan 25, 2017, at 5:17 PM, Kyle Fazzari <kyle.fazzari at> wrote:
>> On 01/25/2017 03:56 PM, Joseph Rushton Wakeling wrote:
>> Hello all,
>> Quick question about version numbering (as in, the `version:` field of
>> `snapcraft.yaml`).  The logical choice here is to use the version of the
>> app being packaged, but what's the recommended way to handle changes to
>> the snap package alone that don't change the version of the underlying app?
>> Is a scheme like x.y.z-n advisable (where n is the revision number of
>> the snap itself for this version of the app), or are there alternative
>> suggestions?
>> More generally, what are recommended practices for setting the
>> `version:` field of snap packages?
> I personally use `version: <upstream version>snap1`. Then if I release
> an update that is snapping the same version of upstream but has
> snap-specific changes (wrappers, part changes, etc.) I can just release
> `<same version>snap2`.
> -- 
> Kyle Fazzari (kyrofa)
> Software Engineer
> Canonical Ltd.
> kyle at
> -- 
> Snapcraft mailing list
> Snapcraft at
> Modify settings or unsubscribe at:

More information about the Snapcraft mailing list