Version numbers for snap packages
spencertparkin at gmail.com
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 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
>> 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
More information about the Snapcraft