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 latest to 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.
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.
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?
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 26.2 then?
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 latest/edge).
@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.
Itâs not possible to rename tracks.