Hello Canonical/Snapcraft team!
We need to create two new track for our app for backwards compatibility. Would it be possible to have the following two tracks created?
PS: snapcraft release -h tells people to use the category “store” rather than “store-requests” which I’m guessing didn’t exist when that help was written. Is there a repo I can submit a PR to to fix that?
Hello,
Per Process for aliases, auto-connections and tracks , we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.
I have three questions before casting my vote.
Thanks!
Hey Daniel, thanks for your reply.
This should be a one-off issue. We’re upgrading from a dependence on zlib@1.2.9 to zlib@1.2.11. 3.15 will become the latest once we can release 3.14 on its own track to maintain an install option for our handful of users still running Ubuntu 16.04, so I suppose we won’t need a 3.15 track. Initially it seemed that requesting both would give us more flexibility.
Thanks Daniel!
Thanks for the prompt and detailed reply!
I have a lengthy response. TL;DR I don’t think you need tracks but if after reading this you still feel you do, we can do this. My aim is to help, not to impede your process in any way.
The thing to keep in mind is the main use case supported by tracks is backward-incompatibility of newer versions of software (the other use case is selecting a major version of the software to stay on, a pattern used by e.g. Node). That is, it covers the case where someone would want to stay on 3.14 because upgrading would mean having to update data files, source code (compilers and interpreters are common users of tracks) and/or otherwise having trouble accessing existing data.
Per what you described, it doesn’t seem to be the case:
So it seems to me like people would have no incentive to stay on 3.14 once 3.15 comes out. Your use case seems well-covered by just publishing 3.15 to the latest/stable channel, at which point all your users would upgrade to 3.15 and have the same (or improved) functionality with no extra work required to migrate or convert data.
You should also keep in mind that using tracks adds friction: users now have to remember to monitor your blog/page and decide if/when to upgrade, and then manually switch tracks, when, assuming your software provides good backward compatibility, you might as well remove that friction by publishing to latest/stable and have everyone auto-upgrade.
You mention the downgrade scenario can be troublesome, but tracks don’t necessarily help here: someone could explicitly choose the 3.15 track, not like it, and then manually have to go back to 3.14, which would get them in trouble. If you use latest/stable, this could happen if someone reverts to the previous version of the snap, but this is not automatic, they’d have to explicitly do so, so in that sense it’s identical to the case with tracks.
You also said:
This shouldn’t be an issue for two reasons: 1) Each snap includes its own local copies of libraries, so you’re not beholden to what the system provides. 2) Even if you are using a library provided by the system, this usually means it’s provided by the base that your snap declares and requires. Because 3.14 can be using the core16 base (Ubuntu 16.04 based build) and 3.15 could use a different base / build (18.04 for example, or 20.04), each snap is independent, isolated and more than one base can be installed simultaneously. If you have tried and had problems with system dependencies in snaps, I’m sure people here can help figure it out in a way that doesn’t require tracks.
Because of the above, I think this case wouldn’t necessarily benefit from using tracks. That said, the pattern you’re requesting is consistent with your release cycle and cadence, so if after considering all this you’re sure you’d like to use tracks, I’m fine with granting them. I would just suggest you consider what I mentioned about tracks adding extra friction for your users, and balance that against the actual need or benefit of using them.
Thanks for your considered response Daniel!
The fact that Snaps can operate independently of the OS library versions is one of the greatest features. We hadn’t been able to get it working with newer versions of our Node dependency, even using some LD_PRELOAD entries, so I was pretty certain we were going to need tracks even after reading your reply.
But I think we’ll no longer need any tracks created, hooray!
In the process of writing out a lengthy reply of my own, I found that a newer version of the Node dependency was released since we last visited this, and huzzah, this new version works out of the box without any extra work required; the best possible outcome.
Thank you very much for your hard work and helpful approach Daniel!
Yay, I’m glad you got it working!
No worries, I’ll remove this request from our queue but if you do end up needing tracks, just let us know.
