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