Version numbers for snap packages
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? Thanks & best wishes, -- Joe -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Version numbers for snap packages
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: 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 `snap2`. -- Kyle Fazzari (kyrofa) Software Engineer Canonical Ltd. k...@canonical.com signature.asc Description: OpenPGP digital signature -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: Version numbers for snap packages
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 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: 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 > `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
