Package-Requires magit 4.2.1

[progfolio]

forge.el declares a dependency on magit 4.2.1.
The latest tag I see in magit repos is for 4.2.0.
Am I missing 4.2.1?

[tarsius]

• The latest forge release (v0.4.6, 0c90606) depends on magit 4.2.0.
• The next forge release (tentatively v0.4.7) will depend on magit 4.2.1, which will be releases a few minutes earlier than the next forge release.
• The current development version of forge needs a version (snapshot) of magit that comes after its 4.2.0 release.
  • This is indicated by bumping the minimal magit version beyond the last release to the likely version string to be used for the next magit release.
  • In the past I would have instead bumped to something like 20250112.123, to be absolutely sure that the package managers would update the dependency to the required snapshot.
  • Nowadays I only do the latter if it is absolutely crucial, i.e., if I changed macros or something like that.

In summary, I think it is a good thing that the dependency declaration of forge says "the latest magit release is not recent enough for this snapshot, you need to use the magit development version, once the next magit release is out, that will do too".

[tarsius]

the dependency declaration of forge says "the latest magit release is not recent enough for this snapshot, you need to use the magit development version, once the next magit release is out, that will do too".

It doesn't actually state that, though. It states "release 4.2.1 is the minimum requirement".

True, but because I saw no other way and because it causes package.el to behave as intended, this is what I have been doing for many years.

I believed this was a non-issue, so thanks for bringing this to my attention. I thought about it some more and realized it should actually be possible to be explicit about it:

;; Package-Requires: ((magit "4.2.1-snapshot"))

Can elpaca and straight handle that?

[tarsius]

Forge now specifies

;; Package-Requires: ((magit "4.2.1-git") (ghub "4.2.1-git") ...)

and I hope that Elpaca understands that.

[Stebalien]

It does not because ghub declares 4.2.0. The fix would be to declare Package-Version: 4.2.1-git in ghub.

[tarsius]

It does not because ghub declares 4.2.0.

That's the original sin, yes. It is wrong to specify the version string using an embedded version strings like this. A tag should be used instead. However, package.el requires it.

I've tried to explain this many times, including to @progfolio. I was not able to convince him. I think the only thing I have convinced him of is that I have gone completely bonkers.

And maybe I have. I have tried to cater to the mutually exclusive idiosyncrasies of the various package managers for years, and it just ain't possible to satisfy them all at the same time. That's bound to push you over the edge eventually, if you don't just give up.

The fix would be to declare Package-Version: 4.2.1-git in ghub.

Of course that's the obvious solution. In my iterations, I have gone through that one too. It causes other issues, this time with package.el and elpa-admin.el, though I don't recall the full details right now. (I have been trying to forget about this, to maintain my sanity.)

It seems that in the long run, the only option I have is to detail all the defects off all the package managers and packaging tools in detail and all at once and with test cases as proof, in the hope, that that finally convinces the various stack holders, that this situation is unsustainable. Doing this is going to cost me a lot of time and will affect me negatively. I have been dealing with this disaster for years, and I so much want to be done with it. But maybe what it takes to get out, is to really dive in one last time.

In the short run I have "decided" to just

;; Package-Requires: ((magit "4.2.0") (ghub "4.2.0") ...)

in the development version of forge. That is of course completely wrong, because it actually needs the development versions of these two dependencies. But I hope that the breakage that results from that, is easier to deal with. It just involves telling users to manually update these two dependencies, which appears to be easier for package users than for elpaca users. Or maybe not, and it results in many issue reports, in which case I am back where I am now: having to iterate through the possible approaches once more. In any case, the next releases come out in two weeks, and maybe in the next cycle the development versions will work with the latest releases of the dependencies.

[tarsius]

I have now dropped everything else to focus on the work necessary to get these three packages into a (collectively) releasable state. I hope that rushing this won't cause worse issues.