Emacs users are used to having a build of the current git master of emacs called emacs-snapshot via a PPA - and there is already demand for a build of the current git version of emacs as a snap. This track should be named snapshot so that it is consistent with the existing PPA name.
As the emacs snap currently uses the latest track to build the latest stable release of emacs (26.2) I think it would be useful to rename this track 26.2 (if possible) so it is clear what version is being used - and then so that future emacs releases can have their own version specific track created as well and each can be maintained separately.
hm, that belongs in
latest/edge and we consistently steer people requesting e.g. “nightly” or “from-master” tracks into using
latest/edge for this.
Sorry It’s not possible to rename tracks.
We can create a 26.2 track and a suitable build of emacs can be published to it (if I understand correctly, you would publish what’s currently in
26.2, but people who are tracking
latest and want to drop back to 26.2 (meaning, not following
latest to get updates as they happen) would need to do so explicitly, which is how tracks are designed to work.
I have to say I find it very strange for a text editor to need tracks; wouldn’t most people welcome a new version of emacs and want to upgrade to it? Does it frequently include backward-incompatible changes in stable releases? (example: My editor is installed from deb packages and I have no idea when it updated from 7.x to 8.x - nothing stopped working or required me to take any action.).
I went checking https://www.gnu.org/savannah-checkouts/gnu/emacs/emacs.html#Releases and the versioning scheme doesn’t tell me much about the release cadence (if any) and how a version’s compatibility with others is reflected in the version number; 26.2 and 26.1 say they have a “wide variety of new features” (none of the highlighted ones seem to me like they’d warrant a track for people to choose to stay on 26.1 explicitly, for instance) or are security or bug fix releases.
Given the above, I have to say I’m -1 to both track requests
Let’s start the 7-day comment period for other reviewers to chime in as well; remember not only my vote counts.
Emacs is a bit strange in that internally it byte-compiles Emacs lisp and this is not necessarily guaranteed to be compatible across major version upgrades - so when users go to use the upcoming 27.1 release, to be safe they would need to first remove any byte-compiled code which was generated from their existing 26.2 install so that it doesn’t silently break on upgrade.
So this presents a problem - if latest were to track whatever the current stable release is, then when 27.1 is released it would be bad form to have latest now deliver 27.1 as we might break existing configurations. Instead users should opt-in to move from one version to another. And so I think tracks provides the best fit for this behaviour.
We could still potentially use latest to track upstream git master (aka what I call snapshot above) but then say 26.2 would have to be designated as the default track so that we still deliver a stable upstream release as the default install.
You could solve the binary incompatiblity issues with epochs. Is the binary incompatibility between say 26.x and 27.y, or is it also incompatible between 26.x and 26.z?
Also, can you automatically migrate the compiled byte-code from version to version? If you can (in some reasonable fashion), you could define a
post-refresh hook that performs the migration and that would allow automatic updates to work properly.
My understanding is that upstream makes a best effort to not introduce incompatible changes at all, but that they don’t guarantee this, in particular across major versions - they have occurred in the past, but I believe this guarantee is stronger across microversions (so 26.x to 26.y should always be fine).
The issue is that users own Emacs configurations are Emacs lisp code and so will likely consist of byte-compiled versions of their code - and this could live in various locations - so I don’t think it is reasonable to go trying and poking in their configurations to automatically try and clean it up etc.
Perhaps then at best a post-install hook could be used to warn the user that they have been upgraded to a new version where the bytecode might need recompiling - but I wonder if this is a suboptimal user experience. So either I ignore the possibility that users configurations could break when major version upgrades occur - and since Emacs major version updates only occur every few years perhaps this is an okay decision - or we go with separate tracks for different versions.
Thanks for taking the time to explain!
Based on these clarifications, I think I’ll change my vote to a +1 for the version-specific tracks; looks like configuration and other customizations need to unfortunately be treated as data files which require a specific version of the application to be read, and cannot easily be converted automatically as you have said. It is not for me to judge the braindeadness of the application’s behavior; however, given this, I think it’s reasonable to model incompatible versions as tracks.
As ijohnson says, epochs may be an alternative for this; if each version bump has a different epoch, existing installs will not upgrade to a version with a different epoch (the upgrade can be forced manually and new installs will get the latest version with the most recent epoch). Choosing which mechanism to use is up to you
Let’s see what other reviewers think about this.
If I were to use epochs, how would users discover a new version is available? Is this exposed via ‘snap info’ as tracks are?
“snap info” would show the newest available version, epochs just prevent systems from automatically refreshing into an epoch-incompatible version.
I’m not sure users periodically “snap info” snaps they already have installed, so I’m not sure that’s a good avenue for promoting this
In that sense, tracks and epochs are similar in that you would need to socialize and inform users how to move and obtain upgrades.
Ok - I think given the prominence of track names on the snapcraft.io store pages and in gnome-software etc I would prefer to use tracks than epochs - @reviewers can you please weight in?
@reviewers ping? Can you please comment on the appropriateness of the requested tracks?
I’m +1 on the tracks, although snapshot is a tricky name since you can have snap snapshots anyway. But it makes sense to align this to the upstream. Epochs would probably make more sense from the deployment perspective, but I think this would be confusing to the users.
Note that while I’m +1 to the 26.x tracks, I’m still -1 to “snapshot” - to reiterate, that’s what
latest/edge is for. Aligning to upstream stops making sense when we start misaligning with the entire snap ecosystem’s semantics for nigthly/snapshot builds.
Whilst waiting to get any ack on the 26.x tracks, I have gone ahead and enabled a new emacs-snapshot recipe on launchpad which will publish to latest/edge, and have changed the existing emacs recipe to publish to beta (which will be manually promoted to stable) for the 26.x or whatever the current stable release is (26.3 was recently released so this is now on latest/stable etc). For now hopefully this is enough to provide ‘snapshot’ builds. The one question I have is I am not sure how to trigger the
emacs-snapshot launchpad recipe every 24 hours or so - is this possible to setup via launchpad or would I need an external service to go and touch the snapcraft.yaml to make this happen?
@sparkiegeek ^^^ I recall you asked about emacs-snapshot builds to be published to edge - any testing or feedback you could give once these start getting built+published would be appreciated.
Apologies, this fell through the cracks! (tracks through the cracks heh)
We’re +2 to 26.x tracks (can you confirm which ones you need? 26.2, right?) but so far +1/-1 on “snapshot” (making assumptions from Igor’s general “+1 on the tracks”). Would you like me to create
Poking our friendly @reviewers, could someone else comment on appropriateness of the
snapshot track for emacs? (at risk of biasing other opinions, just want to point out to summarize that IMO snapshot builds belong in
@roadmr all good - I recently publish
26.3 to latest/stable so if anything this would be the one to make - however I am considering perhaps not worrying and if / when 27.1 is released (which is likely to be next year) then perhaps it might be worth creating a track for that.
I have already started publishing git snapshot builds to
latest/edge as you and others have suggested.
For now, let’s not worry about tracks and I will revisit it if I start getting reports of instability after version upgrades in the future.