Hello,
I maintain the dogecoin-unofficial snap, which grabs the official dogecoin binaries and installs them for the user (https://github.com/slightlyskepticalpotat/dogecoin-unofficial). I would like to offer them the choice between 1.14.3 and 1.14.4, as those are the recent official releases (https://github.com/dogecoin/dogecoin/releases). So, I am requesting the tracks “1.14.3” and “1.14.4” today.
Thanks!
Sorry, but I’m new to using snapcraft and don’t understand what you’re suggesting. Could you please elaborate? If it helps, I’ve released 1.14.4 (the latest release) on the default “latest” track.
Hello!
We’ll start a 7-day comment/discussion period and tally the votes to grant these tracks at the end of that period, per Process for aliases, auto-connections and tracks .
I would like some more information on the requested track names, we typically ask for the same for most track requests.
Do you have any documentation on release schedule/cadence for dogecoin-unofficial or the official binaries you’re packaging? i.e. how long is each official release supported, and how often are new releases made?
Are these versions of the software typically backwards-incompatible? what happens if I was running 1.14.3 and then get updated to 1.14.4?
On a quick skim of the releases page you linked to, 1.14.4 is a “recommended upgrade for all users”, which suggests these point-releases are actually backwards-compatible, and so they wouldn’t be a good use case for tracks - but I’ll let you explain what your thoughts are on this matter.
Thanks in advance!
dogecoin-unofficial mirrors the official releases, which use the major.minor.patch format. Releases have no fixed schedule, but tend to happen once every few months lately. Two new releases are being worked on now, 1.14.5 (next minor) and 1.21 (next major) (https://github.com/dogecoin/dogecoin/projects). 1.14.4 is indeed backwards-compatible and suggested for all users, is this the wrong use case for tracks?
It is. Tracks are meant to be used in cases where there’s a clear need to stay consciously on an older release. As an example, postgresql - you would probably want to stay on the 9.3 track if you were using that, when 9.5 comes out, as migrating is not transparent, and thus the automatic upgrade functionality risks causing breakage for your users.
Another common example is compilers/interpreters; if version 2 of a compiler introduces new language features and deprecates some old ones, users might choose to stay on a v1 track to avoid an upgrade that would cause their code to require updates.
If all 1.14.x releases are compatible and upgrading among them is recommended, you really don’t need to use tracks for them.
