v2.4.3

[kickingvegas]

What's Changed

• Convert over to using transient-define-group by @kickingvegas in Convert over to using transient-define-group #205
  • This is a BREAKING change due to Transient update - Improve format of layout and handling of included groups · magit/transient@bcc0bf8
  • Users should update to latest version of Transient (0.9.0+) on MELPA.
  • The Emacs variable package-install-upgrade-built-in should be set to t.
• Added occur support to Casual RE-Builder by @kickingvegas in Added occur support to Casual RE-Builder #201
• Update Casual RE-Builder screenshot by @kickingvegas in Update Casual RE-Builder screenshot #202
• Add support for Electric Quote Mode by @kickingvegas in Add support for Electric Quote Mode #206
• Merge development to main 20250519_091237 by @kickingvegas in Merge development to main 20250519_091237 #207

Full Changelog: 2.4.2...2.4.3

---

This discussion was created from the release v2.4.3.

[tarsius]

Users should update to latest version of Transient (0.9.0+).

Transient v0.9.0 has not been released yet. It will be released during release week (the first week of every month).

The change to Transient is a breaking change in that packages that use the new transient-define-group won't be compatible with versions of Transient that do not provide that function. I did however try hard to make it backward compatible. Everything in transient--get-layout starting at this line is just for backward compatibility.

I did test this with Magit and Forge. I.e., I compiled them against an older Transient and then switch to the updated Transient without recompiling them, and that worked.

[kickingvegas]

@tarsius also would observe that MELPA practice of pushing out whatever the latest is on main branch for a package is why I'm seeing this before official Transient 0.9.0 release.

[tarsius]

Not sure what your are trying to tell me with that. Yes, that's how Melpa ("unstable") works.

The development version of any package should quickly be updated to restore compatible with the development versions of other packages they depend on, when there are backward incompatible changes in the development version of the dependency. (This would be the case even if Melpa "unstable" did not exist, there are other ways to use development versions. It might be less pressing to do it then, because likely fewer users would be doing it, but still.)

But incompatibilities in the development versions of two packages do not cause their respective latest releases to somehow become incompatible. Latest released Casual was still compatible with latest released Transient, until you created a new Casual release which depends on a Transient release that does not yet exist.

[tarsius]

As a result it is currently not possible to install stable Casual from Melpa Stable alone. Users now have to also add Melpa "Unstable", so that they can install a recent enough snapshot of Transient.

That is unfortunate because (1) they have to figure out that that fixes the issue and (2) making Melpa Unstable will mean development versions of other, unrelated packages will also be installed. When these users originally made Melpa Stable available locally, but not Melpa "Unstable", they did that because they don't want to use development versions.

[kickingvegas]

@tarsius First off, I appreciate your input and the work you’ve done on Transient and Magit. I hope this exchange does not lead into any misunderstandings between us.

On reflection, some observations:

• IMHO the current state of best practices for Emacs package distribution is wildly inconsistent. It is challenging to know what the conventions are, if any.
• For distributing on MELPA, the practice I’ve landed on is to treat both MELPA and MELPA stable as the same. I do not use MELPA to test out code that is not tagged for release.
• What I’ve come to understand with your process is that MELPA is treated as pre-release code (arguably MELPA's original design intent).
• In practice, I’d observe that most MELPA users treat it as released code. While this might be considered cardinally wrong by developers, real-world use has deviated far from developer-intended use here.
• The difference between our practices has landed us to this current state now.

As mentioned earlier in this thread, I think the addition of transient-define-group is great, so much so that I immediately made adjustments to Casual to support it. That said, what I found breaking was my usage of transient-append-suffix to modify an existing Transient prefix that referenced a group defined by defconst. Whether or not you consider this to be a bug or to be a breaking API change is your call.

On Casual now being broken on MELPA stable, while I feel somewhat bad about it, I'm finding it difficult to reconcile with the guidance that I've gotten from the MELPA maintainers themselves as they recommend folks to not use it.

The last thing I want to do is to assign blame, particularly for changes that I think are worthwhile. But I do find value in understanding the circumstances that got us here.

All my best -

Charles

[tarsius]

I hope this exchange does not lead into any misunderstandings between us.

You don't have to worry about me taking offense. If you mean "misunderstanding" in a more literal sense; well, I cannot rule that out, but that is okay.

The Emacs packaging situation is fucked up and it is not getting better. I have been trying to improve the situation for many years, but am now trying to make peace with how things are. As a part of that I try do avoid any conversation about packaging, such as this one, but I keep getting dragged into them anyway. I really have to learn to keep my mouth shut and not provide short, incomplete and unsolicited pieces of advice on packaging, in the hope that the recipient will be able to fill in the gaps. More often than not it instead leads to a follow up question such as yours above, which essentially asks for a complete summary.

Depending on my mood, work-load and level of concentration, I usually proceed to produce yet another short/long, thoughtful/hand-wavy, sarcastic/didactic response. It obviously would be better to stop and instead spend a few hours days collecting past explanations by me and others, and derive the ultimate synthesis of all that, but I can never bring up the energy for that.

---

So this time around, I'll once more try (but fail) to keep it short and sweet.

The main problem is that most (or at least very many) maintainers do not regularly create releases. Many do not even create new releases after fixing very significant bugs. (And by that I do not mean waiting a week or so, to see whether the fix really gets the job done, but not releasing for half a year, or even a few years.)

Some users stick to installing only releases, in the very reasonable expectation, that that would gives them the most stable experience possible. For some packages that it is indeed the case, but it does not correspond to how a significant portion of Emacs packages are distributed/released.

That's why the Melpa maintainers recommend using Melpa "Unstable" over using Melpa Stable. By using the "unstable" flavor you actually get a more "stable" (or rather "less (or at least not known) broken") experience for many (if not the majority of) packages.

Given the current situation, users can choose between installing "development snapshots", which comes with the risk of regressions, or installing releases, which for many packages comes with the certainty of known bugs, which have already been fixed on the "development" branch, as distributed on Melpa ("unstable").

Many maintainers realize that most users use Melpa "Unstable", and unfortunately that also often means that the motivation to regularly release is reduced. So it's also a chicken-and-egg problem. Users don't use releases because for many packages the latest release is severely outdated and/or broken, and maintainers don't bother to release regularly, because "everybody" is using snapshots anyway.

---

So what can a responsible maintainer do, who is aware of this issue?

[I can feel my concentration slipping, so I'll return to that later.]