[proposal] Abolish MELPA Stable #6656
Comments
And even in the Debian case, my experience is that many users are under the false impression that 'stable' means the packages are what i'll call "runtime-stable", i.e. that they work reliably and won't crash (or whatever), rather than "the versions of packages provided in this release are known to work together". i do wonder whether there are users of MELPA that believe packages on MELPA Stable to be "runtime-stable". |
Well, AFAIK the purpose of Debian stable releases is to provide both benefits. A package that crashes and fails to fulfill its basic purpose would be a major bug and would prevent its transition from Unstable to Testing. Anyway, that's a bit off-topic. :)
Yes, that's one of the reasons those who choose it do so. I don't think the false impressions and misconceptions can be solved by explanations or technical solutions. I think we need to just let it go. |
|
I would rather abolish MELPA and leave only the repo where only certain tagged versions are deployed. I personally don’t see the advantage in having any arbitrary commit go straight to a public repo. |
|
these discussions come and go and let's just start with the advantage or at least the motivation behind MELPA for sake of re-iterating. at the time of MELPA's conception, people would go out to all the packages they wanted, clone the repo to their disk, and then do a Now, stable was born out of the desire for package developers to want to tag versions as "stable" or as proper releases. Personally I can say I don't ever use stable and it's something we have added for some of our users who want that behavior. However, its up to the package developers to manage their dependencies. Just like with any software development, if you say "my new stable version of package A requires version 10 of dependency X," but X hasn't released version 10, then there isn't much that any package repository can do except hold back the version of package A. However, whereas Debian has the resources to have package owners, we don't here at MELPA and that's beyond the point. Package maintainers need to manage their own dependencies. Which brings us around to why MELPA was created the way it was in the first place. We pull packages from repositories and we build all the metadata and we bundle all the lisp files because it takes the burden off the package developers. As to my feeling on stable; if someone wants to host their own fork and make improvements I'm all for it. And if the community supports deprecating it I'm all for it. For now it's fairly low maintenance and it's easy to maintain so I don't mind keeping it around understanding it may be annoying for the package maintainers. so going forward, if you want to kill stable your best bet is to stop your packages from being on MELPA and the best way to do that is to either (i) delete your tags or not tag anything or (ii) send a PR that contains a flag for recipes that disables stable for those recipes. Then eventually those packages will stop being built on stable and you'll be good to go. If enough developers make this decision then maybe eventually it can go away. |
|
MELPA: ~4 400 packages. It's would quite some work to get all those as-yet untagged packages tagged so that they can be available on Stable. Losing roughly half the MELPA ecosystem probably wouldn't be a good thing. :-) |
|
I’ll amend my point - if you abolish stable, then let’s also allow each package owner the ability to deploy only tagged versions if they choose. |
|
Please keep something like MELPA Stable around. It's valuable to me to know that I can, by default, install or update to the latest version of a package as decided by the package maintainer. Though since I keep all dependencies under my personal source control, I also have a solid approach to rolling back breakage, and so perhaps do not feel the pain from Stable's disadvantages. For packages which use non-date-based version numbering, MELPA's date-based scheme is disorienting. It's nice to be able to look at package release notes and immediately correlate it to the version shown by M-x list-packages. MELPA Stable helps with this immensely. I know that I, as a package maintainer, take extra care to make sure that the versions I tag have undergone more thorough and longer testing than the things I push to master (though of course I try not to break master). It is valuable to me that people who use my software can rely on a tagged version and have an easy way to install it. I also know that I, as a package user, do not much enjoy having tons of churn when I go through my occasional package update cycle. More churn = more breakage. Stable reduces this churn. If the decision to abolish MELPA Stable is made, then I guess I could switch to a different package manager, but evaluating the whole lot is a bunch of work. Which one has the ability to run a simple command saying "update to the latest tagged version of all packages", doesn't require git submodules, integrates cleanly with use-package, and trivially lets me keep checking my packages into source control (i.e., lets me keep my package management largely unchanged)? |
|
Great discussion, and thanks for raising the proposal, @alphapapa. I guess I'm not keen to abolish MELPA Stable completely if it's genuinely useful to some people. The messaging around MELPA Stable is clearly unhelpful, so I'd definitely consider:
It reduces the churn, but at the cost of greater likelihood of breakage when a new version of something is released, since that new version wraps up a bunch of smaller changes that you could potentially have adapted to along the way on "non-stable" MELPA. In reality if you don't want to freeze all the installed packages with git or similar, you still need to be careful about updates and have a way of rolling them back temporarily while upstream fixes are made, and this applies equally to both MELPA archives.
Fwiw, an ideal solution here would be #2955, which would integrate MELPA's snapshot versioning with upstream versioning. If
Yes, in theory you can opt out of MELPA Stable by setting the version regexp in the recipe to something that will never match. I wouldn't particularly encourage authors to do this, though, because I don't think they are individually best placed to decide how all their users would like to install their packages. |
|
I'd also consider including a more strongly worded and reasoned statement here about why users should prefer regular MELPA. |
|
Emacs has been around since the 1970's. Emacs package management is slightly more recent. Marmalade, MELPA, milkypostman's archive -- package repositories -- are even a bit more recent. And as someone who's contributed one or two packages to MELPA over the years, I know that the attention ported to the quality and compatibility of package code has been increasing. I think we're relatively early in a multi-year journey, and I believe that abolishing MELPA stable would be throwing out the baby with the bathwater. As has been pointed out above, there's no way to control what package authors and maintainers do / choose to publish, and building a more complex package dependency resolution tool for emacs packages will take time. I do believe that it's a worthwhile endeavor though, and if we abolish MELPA stable we're also cutting short all progress we make towards a healthier ecosystem. I'm incredibly thankful to @purcell and all the feedback he has provided me on my packages over the past few years, as well as to the contributions he has made to the ecosystem to facilitate package creation and contribution. I think the renaming to "Releases" is a good one and may help with expectations. I also think the snapshots would be an interesting addition... I can also imagine a world where we relegate the git-based releases to integration with the package repository, not for public consumption |
|
Perhaps one additional improvement would be to merge the two websites into a single view?
The literal table layout / design isn't my focus nor my expertise. The point is first to remind users that there are two streams of release artifacts (snapshots and tagged releases). Second, to make it clear that many packages don't issue tagged releases, for reasons discussed above and elsewhere. Third, to show the date of the most recent snapshot relative to the date of the current tagged release as a visual cue. In the given example, the most recent tagged release of |
This could be nice. |
|
I think @purcell 's point
is spot on. You can see from the recent proliferation of package management solutions that people feel very strongly about packaging and installing packages (I myself expressed quite strong opinions about some shortcomings of MELPA). With time we can all agree MELPA made the Emacs world better. But ultimately it's up to the users how they decide to manage their own setup. When I get these breakage reports these days I say "I'm sorry but this is out of my control, consider using straight.el instead of package.el". Unless they come back with a specific feedback, I leave it at that. I like @gonewest818 's proposal of merging the data into one view. My current position is that while convenient, package.el is too simplistic and provides no strong guarantees about the installation set. So to me the best way forward would be to abolish that instead of a specific archive. MELPA still has a great role serving as a catalogue of all the stuff out there and other package management solutions, like straight.el, use it for looking up packages. |
I don't even think the name should be renamed. They both make sense to me. @gonewest818 idea is good! But I am also good with current view. I think this is somehow related to this issue here #6319? |
|
Hi, I'd just to thank all project maintainers who tag releases for tagging releases. In Debian we provide deb packages that integrate with package.el and with peculiarities to Debian-like (Ubuntu and other derivative) systems (ex: fd is installed to /usr/bin/fdfind, so upstream source needs to be patched). We also do distribution-level QA to make sure all the packages work properly, and work properly together. Ultimately we try to provide a good first-contact experience for users of your software, knowing that users may switch to the MELPA unstable stream to get newer versions. In a team discussion about the possibility of a future without tagged releases, it was noted that a likely consequence of this would be that the versions in Debian would lag far behind upstream HEAD, because it shifts the question of "is package X ready for a users to use for three years at commit Y, and will it break any other software" to people who aren't 100% appraised of all potential issues for a project. So we'd sincerely appreciate if you would continue to tag stable releases so we don't need to resort to arbitrary cut points based off of git snapshots. Sincerely, |
Just to make sure I'm being clear: I do not propose that package authors should stop tagging releases--quite the opposite. My proposal is only about the way those tagged releases are distributed in MELPA Stable. As a long-time Debian and Ubuntu user, please keep up the great work! |
@alphapapa, thank you for the clarification, understood. Likewise, my concern is specifically with @milkypostman's proposal in the last paragraph of #6656 (comment).
Thanks, will do! Also, I'll forward your message to the rest of the team since it may brighten their day :-D |
|
@alphapapa just because something does not serve you well does not mean it needs to be abolished. Take a deep breath. To @purcell @milkypostman and the rest of the MELPA crew, I thank you for your continued great work and giving users freedom of choice. |
|
@rnkn Please read the technical arguments. It's not about me. |
|
@alphapapa What you've provided aren't technical arguments but rather opinions about how a person outght to do things in a technical context, and given MELPA Stable does not fit with your opinions, you've proposed it be abolished for all. This perspective of my way should be enforced on all bothers me. Sorry but MELPA Stable is something that many people find useful and perfectly suits their way of doing things. Can I ask that this issue be closed? I see that this proposal has all but been vetoed in the above comments, which is heartening, but keeping it open gives the disquieting impression of dangling an axe over MELPA Stable's head. |
|
@rnkn Perhaps you are new to this topic. The problems with MELPA Stable have been discussed for years, e.g. in the 4 issues I linked at the bottom of my comment. Feel free to read them and learn about the issues. As well, perhaps you overlooked this simple explanation of the technical problems it causes users:
Now, I would appreciate it if you did not mischaracterize my arguments this way:
This is not about me. This is about users being misled and having their configs broken. Finally, consider the irony in your own words:
Please consider adopting a friendlier, more reasonable attitude in your future comments. |
|
Both of you, be nice to each other! |
|
@alphapapa I did read your posts. To address your main concern;
I understand that you think of this as a technical argument. If you'll take a step back for a second, each of these is just: the assumptions of what others' impressions are of what "stable" means and how it ought to be used; the assumption of how others set up their Emacs configuration; and the assumption of what other package maintainers consider enough effort in keeping their versioning consistent. You've then extrapolated each to a universal. How do I know these assumptions are not universal? Because I use MELPA Stable (both for distribution of my own and installation of others' packages), it works well and I quite like how it works. Many people do. Perhaps it works well for us because we do things a particular way. Perhaps it does not work well for you (and others) because you do not do things this particular way. That's not a problem. Certainly not one that warrants abolishing the thing entirely. Given you feel strongly about this, maybe you should direct your energy into building an alternative, and if it's better we can all use that instead. |
|
Up above purcell stated a position: "I guess I'm not keen to abolish MELPA Stable completely if it's genuinely useful to some people." Not possible to say how many people consider it useful but the MELPA stable download stats show how much stable is used. The most downloaded packages on MELPA have a ratio of about 50:1 (MELPA : MELPA stable). So, not a huge percentage but also, not zero. |
(require 'dash)
;; https://melpa.org/download_counts.json
(setq melpa-counts
(with-current-buffer "melpa_download_counts.json"
(goto-char (point-min))
(json-read)))
;; https://stable.melpa.org/download_counts.json
(setq melpa-stable-counts
(with-current-buffer "stable_download_counts.json"
(goto-char (point-min))
(json-read)))
(setq melpa-ratio
(-mapcat
(lambda (p)
(let ((melpa-dls (alist-get p melpa-counts))
(stable-dls (alist-get p melpa-stable-counts)))
(when stable-dls
(list
(cons p
(list (cons 'melpa melpa-dls)
(cons 'stable stable-dls)
(cons 'percent (/ (* 100.0 stable-dls)
(+ melpa-dls stable-dls)))))))))
(-map #'car melpa-counts)))
(alist-get 'dash melpa-ratio)
;; => ((melpa . 2587339) (stable . 46864) (percent . 1.77905803007589))
(alist-get 'magit melpa-ratio)
;; => ((melpa . 2169060) (stable . 30107) (percent . 1.3690183601336323))
(setq melpa-dls (-sum (-map (lambda (p) (alist-get 'melpa p)) melpa-ratio)))
;; => 149647429
(setq stable-dls (-sum (-map (lambda (p) (alist-get 'stable p)) melpa-ratio)))
;; => 1762372
(/ (* 100.0 stable-dls) (+ melpa-dls stable-dls))
;; => 1.1639748473085967 |
@rnkn has now blocked me on GitHub. I noticed because I was going to star his nice-looking https://github.com/rnkn/olivetti package, but "You can't star at this time," and the Follow button is not shown on his GitHub profile. I've never even spoken to him before. This is the only communication we've ever exchanged. Am I really the one being unfriendly here? 🤦 |
|
Seems like a storm in a teacup to me. Your weren't being less friendly than he was. While it's good to strive for a neutral tone, we cannot expect each other to robotically control our affect at all times and it's not reasonable to face lasting repercussions for an off-hand statement. I didn't read your original proposal as hostile, just passionate about technical matters. |
|
On the topic of the thread, as a practical matter MELPA stable currently has so few users compared to ordinary MELPA that I keep forgetting to tag releases (even though making a release simply by Hence, as others have noted, I don't think my stable releases end up being any more stable than the ordinary version. Sometimes they are missing bug fixes that affect a few people. Would it be possible to automate stable releases? Something along the lines of "a version that has been downloaded by X people and hasn't been updated in Y days is marked as a stable version"? There are some implications to consider here: for example, a really fast-moving package would rarely if ever get a stable version. Perhaps the download counter should be proportional to total number of downloads for that package. If this kind of automated system is adopted, "leading edge" and "trailing edge" would be more descriptive names for the repos, though a bit wordy. One of my favorite things about MELPA is that the leading-edge packages generally work just fine; the pun "bleeding edge" is not warranted. |
That would be similar to Debian's Testing and Unstable archives: a package is initially uploaded to Unstable, and after so-many days without a serious bug report, it's automatically migrated to Testing. Overall it works very well, and it makes Testing a pretty reliable "rolling" release. In the context of MELPA, it's an interesting idea. However, lacking a centralized bug tracker with consistent metadata, such migrations couldn't easily be based on bug reports. So, as you said, there are at least a couple of criteria that could be used:
Overall, I like the idea. It would be much more useful than the arbitrary tagging that most packages get. |
|
Thank you for the thoughtful remarks.
Great! I have only used Debian stable and didn't know this has already been proven.
Do you mean generating more downloads to mark a package as stable sooner? It would probably do little to no harm - with the current system, maintainers can already publish a stable version any time they want. An automated system would increase the amount "peer review" based on the current system even if some maintainers do game it. We could even retain the current ability to manually make stable releases as a failsafe option to the automated releases. Since leading-edge packages are generally so stable, it's probably ok if packages inadvertently get marked stable more often than they now are.
Not crazy - I also thought this might make sense :) GitHub and GitLab probably have APIs that make it easy, even. What isn't so easy is to differentiate between:
This could be done by tagging/labeling the issues, but that's easy to forget. |
|
@didibus Your expectations are entirely reasonable from a theoretical standpoint but that's not what we see in practice. Much like rolling-release Linux distros can be easier to use in practice than the traditional point-release distros that are easier in theory, the cutting-edge MELPA is probably easier in practice than Stable. It's like dynamic typing in programming languages - in theory everything should go wrong, but in practice it's almost a non-issue. Tying into @purcell's comment, probably a major part of what makes MELPA work well is that packages quickly learn not to break the master branch. Topic branches also sound like a good idea in theory but in my experience, projects where topic branches deviate a lot from master inevitably run into problems. Humans cannot deal effectively with so many moving parts at once. So the rolling-release model ties neatly into the ideal software development model where a package is mostly developed in one direction at any given time, with changes integrated early and often into master. |
There is the occasional breakage, but MELPA users are very helpful and will quickly report it in your issue tracker. Many even send PRs. There's a cultural expectation that some package or another may break every once in a while; it's not considered a blemish on the author's reputation if it's just a simple oversight. TL;DR please give it a try and trust in the community :) It's a good one. |
@gonewest818 it's not true that in standard MELPA any random commit goes directly to users. Package maintainers already indicate which version of their software is usable by selecting a git branch to install from. Unstable code usually lives in separate feature branches. As a package maintainer, I think MELPA stable is largely a nuisance. I wasn't aware that my packages were available there until users started complaining that the stable version is horribly outdated. As a user, I've never had a problem with standard MELPA. I love it! If MELPA stable continues to exist, there must be a way for package maintainers to opt out. I have no interest in maintaining two separate versions of my software nor do I have time for that. |
|
I’m also a package maintainer. So my issue might not be universal, but it’s not invalid. I’ve seen packages broken by very experienced developers committing to to the branch that goes directly to the users. Trust the community to rapidly fix it, yes that is how this is working out. |
|
We have two schools of thought among package maintainers: “push it all to This leads me to conclude that ELPAs as a concept fundamentally suck for some fraction of maintainers by forcing them into a release cadence they disagree with. Each ELPA will annoy a different group, depending on its choices. Because MELPA availability is a de facto requirement for an Emacs package to get any attention at all, this means its choices are the only ones that matter, and everyone has to suck it up and keep The right thing, quite frankly, is to decouple |
i.e. Quelpa? Anyway, I have an idea for a "Distributed ELPA" ("DELPA"?) which would allow anyone to publish a list of packages, endorsed versions/tags, and the git repo URLs (you could support other VCS's if you want). Then users could "subscribe" to multiple DELPAs according to whose judgment they trust. So, e.g. Spacemacs could have its own DELPA repo (rather than actually building and hosting their own MELPA mirror), and Doom could have its own (e.g. ensuring a set of package versions that work with Doom's config), and John Q. Emacsuser who wants to publish his config for others to use could do the same. And, of course, users could subscribe to ELPA and MELPA as well. All of the packages would actually be retrieved from their source code repos, ala Quelpa or Straight or Borg. Similar to a BitTorrent site hosting magnet links or .torrent files, all that would have to be hosted in a DELPA repo would be the package names, version tags, and git URLs (e.g. it's just a text file which could easily be served from So, basically, the idea would be, if a user is dissatisfied with the stability of the package versions they're using, they could subscribe to the DELPA of someone else who more carefully vets packages for stability and integration. Or if they want the bleeding edge, they could use "raw MELPA." Or maybe they want to use an older Emacs version, so they could subscribe to one that guarantees compatibility with it. etc. And like Quelpa, it could sit on top of the existing Just an idea. |
It may be that individual maintainers want to stick to their guns. For me and for many others, once we saw how much better development works (faster pace, fewer bugs, easier to react to unforeseen circumstances, easier to hold a mental model in your head) when master is kept on a strict course, we never went back to the old clear separation between development phase and cleanup-for-release phase. When master is kept clean at all times, release and development blend into a kind of hybrid. Official releases are then more of a political formality than a technical process. This is how we reconcile the two camps for ourselves. In the case of Emacs in particular, packages have so many environmental dependencies (on other packages, non-Emacs software, OS, user and site configuration) that it's not really possible for maintainers to test their own packages past a certain point. This was a bit hard to accept but soon I learned to stop worrying, code a bit cautiously, make big changes in smaller increments than before and trust other people to report anything broken.
Trivial fixes:
|
I tried it a while ago, and saw it had to pull down the entire machinery of an ELPA. That doesn't sit well with my tastes in software development: too much of a heavy workaround for what should be a self-contained package manager. A distributed ELPA of the type you suggest is intriguing. If I understand correctly, you're proposing simplifying the package repository to a metadata database? |
I don't know what you mean by that. When used with MELPA, by default, it clones the MELPA git repo so it has a copy of the recipes. Without that, it wouldn't know where to retrieve the packages' source code unless you manually specified every recipe, which would become a tedious chore in the case of dependency chains. But if you want to do that, you can disable the cloning of MELPA and specify all the recipes yourself.
Basically, yes. I imagine interested users maintaining their own metadata repos, which could be layered onto others. Alice could have her own DELPA with very high standards, only accepting packages that meet certain criteria. Bob could have a DELPA that accepted anything, even packages hosted on EmacsWiki. Chuck could subscribe to both, with Alice's being a higher priority, and maybe asking for confirmation before installing a package from Bob's. Maybe he'd automatically upgrade packages from Alice's DELPA, but not from Bob's. I think it would offer a lot of flexibility and open up interesting possibilities. One might object that it might contribute to fragmentation, but I think some of that is naturally occurring already: there was once Marmalade, then MELPA, and now alternative package managers like Straight, Quelpa, Borg, Feather, etc. are already gaining popularity. Spacemacs already hosts its own mirror, and other MELPA-like mirrors exist already. Given that, it seems like the chief advantage of having a centralized repo like MELPA is that all the metadata about packages can be retrieved at once, rather than having to |
|
This is a fantastic idea. One thing I'd like to see: no Git dependency in the package manager. (1) It will make it possible to install packages on more limited machines. (2) I like to keep my configuration fully checked in, packages included, |
Well, the source code has to come from somewhere. It either comes from archives, which we already have with ELPA/MELPA-hosted tarballs, or source code repos, which we already have with Quelpa, Straight, Borg, etc.
I do that as well, but it's not necessary for copies of git repos to be included. When I install a package with Quelpa directly from one of my repos, it runs So I think what you're asking for is already the case with the tools we have. |
|
Thanks for the insights about Quelpa. I clearly should have RTFM. 🙃
My instinct is still to avoid a Git dependency, and retrieve from the repositories with HTTP. |
I think this describes the debate pretty well. I'd like to add though, it does seem like right now we have the worst of both worlds. If you are "push-it-all-to-master", your users who switch to stable because they think that's where stable release lives will get outdated releases of your package instead, with less features and less bug fixes, thus it'll be a worse experience for them. If you are a "mark-releases-my-master-is-unstable-otherwise", your users might not realize it, and since Melpa doesn't default to stable, unless they explicitly lock the package to Melpa stable, they'll keep getting your broken, not ready to be consumed commits. In both cases you get a less then ideal scenario. I wonder if changes to the recipe could be made to address this. If the recipe itself could specify the default Melpa to use, package authors could choose to default users to tagged stable releases if that's their release style, and if that's not their style they could mark it as Mepla only, which would redirect users consuming from stable to Melpa releases for that specific package. |
Speaking as a user, the most common problem I run into is packages having a tagged release at some point and then the author/maintainer doesn't keep up with tagging later. Essentially, if I use both melpa and melpa stable, with stable preferred, then the author/maintainer is in control of which approach I get - until they stop releasing "stable" after having started at any point. A way to simply turn that back off, along with awareness on the part of maintainers, would probably resolve those issues. |
|
I tend to agree with what @gcv said above about different kinds of package maintainers and their (to an extent) mutually exclusive preferences of doing things. And while I agree with @lassik's post that you can resolve resulting tensions to an extent (I myself use a
Here's a hypothetical example to illustrate the points I made: Maintainer A has a package |
Really excellent idea! By far my favorite suggestion so far. This would double as a non-intrusive way to tip off maintainers about the state of their own packages. I simply don't remember when I last published a stable version of some package. |
|
Pardon the tangent, but I ended up here because I was looking for a resource which explains when and how something ends up in MELPA stable. Could the bug description please be updated to include a link to suitable background information? I honestly kept on googling for a good while but just found myself going in circles. This is the closest so far I have gotten to a background exposition: https://www.reddit.com/r/emacs/comments/etikbz/speaking_as_a_package_maintainer_please_do_not/ (by the submitter of this issue) |
|
MELPA Stable watches for commits with tags:
|
After having received a few more complaints about incompatibilities related to MELPA Stable, I have come to the conclusion that MELPA Stable should be abolished.
In every case I've seen, users who use it do so thinking that it's something like Debian Stable or Testing, and that they are making a smart, informed decision to use MELPA Stable. They think that whenever breakage happens, it's due to lazy or incompetent package maintainers. Of course, these same users freely upgrade all the packages in their config to whatever happens to be available at the moment, taking no care to commit installed packages to version control so they could revert breakage, or use alternative package managers that allow pinning.
I don't necessarily blame them for their misconception. As users, they can't be expected to know the technical details of how the Stable repo is built. Debian being the obvious namesake gives a false impression, and there is no big, red warning on stable.melpa.org informing them of the reality.
AFAICT, MELPA Stable provides no benefit to anyone. It gives a false impression to users, and it leads to extra breakage in their configs. Maintainers do not coordinate API transitions on Stable, even within their own packages (I am guilty of this myself, but it wouldn't be worth the extra paperwork to do so), and this leads to more frustration when users are caught in the middle.
Therefore, I propose that 3 months from now, the versions of packages on MELPA Stable be frozen (i.e. they cease being rebuilt), and 3 months after that, the repo be taken offline. That would give time for users to be informed and transition their configurations to regular MELPA or other package managers.
After the "band-aid" is removed (not even ripped off, with such a gentle transition), alternatives could be explored freely, without the associated ideas and "baggage" that the term "Stable" brings.
Lest I give a false impression, let me express my gratitude for MELPA and all those who have contributed to it. It has undoubtedly been responsible for much of the growth of the Emacs community in recent years. MELPA Stable was a nice idea, which I have supported in the past, but due to technical realities, it just doesn't work in practice. It's dying a painful death, anyway. Let's put it down gently and look for a new puppy. :)
If this proposal is not acceptable, I would ask that packages be permitted to tag stable versions while opting-out of having them be built on MELPA Stable. It would be better for me and for users of my packages.
Since I am making a specific proposal, I'm filing it as a separate issue.
Relevant issues:
The text was updated successfully, but these errors were encountered: