Consider dropping melpa stable

[belak]

I had someone show up in the Emacs IRC channel on Libera today asking why some themes were missing from the base16-emacs package they installed. It took a while to figure out they were using rational emacs and that rational emacs defaults to using melpa stable.

My proposal is to drop melpa stable from the default list of repos. Even the MELPA maintainers don't use it (see here where they say "Note that the MELPA maintainers do not use MELPA Stable themselves, and do not particularly recommend its use.").

I do understand why this was done - logically, it makes more sense to always depend on "released" versions of packages and because those packages change less frequently, you have to update code using them less. Unfortunately, I don't think most Emacs package maintainers tag releases (I tend to do it only when people ask or when I have a clear changelog item).

On a related note, but not super relevant to this conversation - this is one of the advantages straight.el provides. You can pin packages to a specific version, so you can avoid breaking your setup until you're ready to try upgrading some of your packages.

[jeffbowman]

Thank you for your comments!

I also understand that MELPA maintainers don't use MELPA Stable, nor do they recommend it. I find their stance a bit ironic as packages which have dependencies mention a released version for the dependency.

However, for people who don't want development versions, using MELPA is a problem. The constant changes and updates and potential breakages that occur make using it unfortunately frustrating (that said, Emacs only stopped working for me after updates a few handful of times when I was following MELPA only - so the breakage frustration thing is a low-ish risk). It's also difficult to tell which actual version you have. The package frequently has a version at the top, but the installed version is a date stamp. The base16 package has a version of 1.1 in one file and 2.1 in a different file but the most current tagged version is 2.3. Not trying to stir a pot, just highlighting how it can be confusing to understand what version is installed especially when following a development snapshot (ie MELPA release).

So, no one really wins here. Not everyone is willing to follow packages in development mode, but not doing so means they are missing features and fixes because it might be years between releases. When someone using Rational Emacs adds an issue about a broken package, I do try to help figure things out for them. Assuming the fix is on the master branch of some package, I suggest they reach out to the maintainer of the package in question and request a release. I also show them how to get the MELPA version of the package in case they don't feel comfortable asking for a release or if the maintainer prefers not to make one at that time or whatever.

For the person who came to IRC, they submitted #148 here. So, I tried to find the missing theme in the project. Unfortunately, I missed seeing it (I didn't look in the build directory, my bad). At a loss of how to help, I suggested they contact you for assistance.

I think I need to add some "Troubleshooting" documentation to the project. I'll start working on that asap. Would you mind releasing a new version of base16-themes (assuming you haven't already)?

On the subject of using straight.el, one of the principles Rational Emacs is based on is to prefer built-in functionality as much as possible, so we prefer using package.el (discussion on issue #94). There is an example configuration if someone wishes to use straight.el instead. Even using package.el though, a package can be pinned to a repo and it is possible to cause a package to never be updated, but there is a bit of effort involved; its certainly not as smooth as using straight.el. For the majority case, though, if a user knows how to install a MELPA package directly using package.el that would probably help with version related issues similar to this one.

[belak]

So, no one really wins here. Not everyone is willing to follow packages in development mode, but not doing so means they are missing features and fixes because it might be years between releases. When someone using Rational Emacs adds an issue about a broken package, I do try to help figure things out for them. Assuming the fix is on the master branch of some package, I suggest they reach out to the maintainer of the package in question and request a release. I also show them how to get the MELPA version of the package in case they don't feel comfortable asking for a release or if the maintainer prefers not to make one at that time or whatever.

I appreciate your opinion on this - it does seem weird that the Emacs community seems to focus on development versions of packages instead of encouraging developers to release stable versions. Most of my packages are themes, but you've convinced me to make sure I'm tagging versions when possible.

For the person who came to IRC, they submitted #148 here. So, I tried to find the missing theme in the project. Unfortunately, I missed seeing it (I didn't look in the build directory, my bad). At a loss of how to help, I suggested they contact you for assistance.

Not a problem - thankfully I have my client set up to ping me whenever someone mentions base16 in the Emacs channel, but I almost missed it. Filing an issue on Github would also have worked, though sometimes it's easy to miss those too. For future reference, you can find recipes for packages in the melpa repo. As an example, the base16-theme recipe can be found here. Admittedly the build folder is a little non-standard, but it's done because there are so many files in there that most people don't need to care about when working on the theme.

I think I need to add some "Troubleshooting" documentation to the project. I'll start working on that asap. Would you mind releasing a new version of base16-themes (assuming you haven't already)?

Yep, I've already released a new version of base16-themes (2.3 was tagged earlier today). However, as you mentioned, I accidentally left 1.1 in the primary .el file, so I just bumped that to 2.4 and tagged it, so it'll show up in melpa stable in a few hours, whenever the next build happens. I forgot the other file, but that one's not as important so I'll just wait for some actual changes to release a 2.5.

I'm not sure the best way to phrase it, but it seems like "There's a feature a package has which seems to be missing when installed" would be a good troubleshooting entry for melpa-stable vs melpa-development.

On the subject of using straight.el, one of the principles Rational Emacs is based on is to prefer built-in functionality as much as possible, so we prefer using package.el (discussion on issue #94). There is an example configuration if someone wishes to use straight.el instead. Even using package.el though, a package can be pinned to a repo and it is possible to cause a package to never be updated, but there is a bit of effort involved; its certainly not as smooth as using straight.el. For the majority case, though, if a user knows how to install a MELPA package directly using package.el that would probably help with version related issues similar to this one.

I understand the rationale - it makes sense. One of the things someone mentioned in that issue was that straight.el would probably only make sense if it provided enough additional features over package.el. It probably doesn't belong in this issue, but I was pointing out that you can pin packages to old versions with straight.el, while package.el is limited to only the versions available in the repos (and each repo only has 1 version of each package available). Doom-emacs uses this to great effect - it means if you clone a specific version of doom, you know all the packages should work together. Though, doom also has tooling to update the pinned version. This makes me curious for my own config if you can pin to tags using straight... I'll have to check that out. EDIT: there's a rant I've seen on Reddit about this, but I can't find it at the moment - it was essentially saying that 'stable' isn't actually 'stable' because it's still a rolling release and package maintainers could still release incompatible versions at any time and you can't go back to previous versions.

Anyway, thanks for the background information! I think you've made the case that leaving melpa-stable in makes sense and I'll try to remember to cut an actual release of my packages once in a while.

[jeffbowman]

there's a rant I've seen on Reddit about this, but I can't find it at the moment - it was essentially saying that 'stable' isn't actually 'stable' because it's still a rolling release and package maintainers could still release incompatible versions at any time and you can't go back to previous versions.

I've seen this rant I think (https://www.reddit.com/r/emacs/comments/etikbz/speaking_as_a_package_maintainer_please_do_not/). One of the things that rant posited was the lack of testing between packages and that any single package would not/could not force dependent packages to meet quality requirements when moving to the next version. While there is truth to this statement, it misses the point that a package author is really only "responsible" for their own package. If they need a newer unreleased version of a package, they can ask that other package maintainer for a release or they can continue to use the released version. The Java community does this already. The big difference, though, the Java community has maven, which hosts multiple versions. The problem with Emacs is there can really only be one. So, if you used dash for example and wanted version 2.1 but another package wanted version 3.1, which version would be loaded when Emacs starts? Which version should be loaded? What happens to your package that hasn't adopted the breaking changes in version 3.1 of dash. This, I think, is the biggest reason why development packages are used rather than released versions. I really appreciate this conversation because, at a minimum, it demonstrates that 2 maintainers of very different packages can work together to find a solution. What would it be like if all maintainers worked together like this? I picked on dash because somewhere in my configuration I have something that uses the obsolete dash-functional package and there is a message in my *Messages* buffer about it. As a user of a package, I'm part of the conversation, so I need to go find where that is coming from and ask the maintainer for an updated release, or switch to using the development code (which I prefer not to do at the moment).

I believe this particular issue highlights the points made in the rant you mention, but also highlights how the community as a whole could be a bit better. The author of dash-functional did the "right thing" (tm) by marking that work obsolete and suggesting the fix. The downstream users of that package now know they need to make an update to their code and release a new version. Users of their packages also know, because the message appears in their Emacs *Messages* buffer. So everybody knows, and yet the "fix" hasn't happened.

Anyway... I'll get off my soap box now. :-)

Thanks for reaching out, I do appreciate it very much. I tried to leave a helpful comment on tinted-theming/base16-emacs#79 which is a strategy I use successfully, maybe it would work in the context of that issue as well.

I'm going to close this issue, but feel free to come back and leave a comment here if you wish.