Version numbers for snap packages

[Spencer]

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 canonical.com> 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 canonical.com
> 
> -- 
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft