Fix: Add version comment.

[KJ2ME]

Hi, i tried today to use magit-todo and find that hl-todo show as a version 0.

It's a sole line fix :).

[tarsius]

In my opinion it is wrong to embed version strings in source files that are checked into git. The main argument being that such strings are only correct for one commit (the actual release). For all commits that follow, right up to the next release, the embedded version string is a lie; it claims to be, e.g., 1.0, when in reality it is "1.0 plus an unspecified number of commits that have not yet made it into a release".

In my opinion it is better to not provide version information than to provide incorrect information. Or rather, to provide version information using an adequate mechanism. Git tags are such a mechanism and I do tag my releases.

The author of Elpaca strongly disagrees, and he has expressed the hope that I will change my mind. Likewise, I hope that he will do that. At this time there is no point in the two of us discussing it again.

I do believe Elpaca has mechanisms to deal with packages that don't specify the version in the way that Elpaca wants them to be specified. It seems that in this case they are not kicking in, or maybe I misremember.

So it seems we have to summon @progfolio after all.

Nicholas, I do realize, that what I am doing is just wrong in your eyes, but since I do not intend to change my evil ways, let me suggest a workaround. (For all I know, you might already be doing something like that, and it just doesn't work in this case for some reason.) When the package "does not specify" the version (aka the version is 0), then ignore the minimal version requirement specified by a dependent package.

And if you don't want to do that unconditionally, because you suspect that this situation may also arise due to a genuine mistake, as opposed as the stubbornness of this particular package maintainer, then let me suggest you deal with this, the same way I (as author of the Borg package manager and maintainer of the Emacsmirror) too have to deal with stubborn maintainers that just won't yield; by adding a special case for that one stubborn holdout.

[progfolio]

In my opinion it is better to not provide version information than to provide incorrect information.

For anyone else reading this, there's a third option you've omitted: Provide a semantic version for changes to the package.

I do believe Elpaca has mechanisms to deal with packages that don't specify the version in the way that Elpaca wants them to be specified.

It has several. I've left the decision up to the user.
It's currently possible to:

• Alter the package recipe to request a full clone so the latest tag can be determined:

  (elpaca (hl-todo :depth nil))

• Use a specific release of the package:

  (elpaca (hl-todo :tag "v3.6.0" :pin t))

• Manually provide a version string:

  (elpaca (hl-todo :version (lambda (_) "3.6.0")))

• Disable version checking for the packages involved (not recommended).

When the package "does not specify" the version (aka the version is 0), then ignore the minimal version requirement specified by a dependent package.

That undermines the whole point of version requirements.
It's not the dependent package maintainer's fault the maintainer of the dependency eschews versioning.
Ignoring the issue leads to hard-to-debug issues (which I'm sure you've received as a result of straight not checking version requirements) and general distrust of, or frustration with, the package manager.

let me suggest you deal with this, the same way I (as author of the Borg package manager and maintainer of the Emacsmirror) too have to deal with stubborn maintainers that just won't yield; by adding a special case for that one stubborn holdout.

How does Borg handle package version requirements?
Regarding special cases, see above. I have plans for more workarounds, too.

[tarsius]

Nicholas, I have the deepest respect for you and you work, and I hope it is fair to assume you feel similarly about my work. We do have some fundamental disagreements on some important technical matters, but that is fine, such things happen. It is more important to preserve a good working relation than to resolve all disagreements.

That being said, I think we might be able to work something out. We should at least try. I would like to do this privately over email, and will send a first message soon, hopefully within a few days.

I think it is better to do it privately than, e.g., in response to a pull-request like this, "there is a minor defect in your package, which can can trivially be fixed like so". That puts me on the defensive, which results in me leaning towards slightly more snarky/unyielding/... wording than necessary/productive. Which in turn sets the mood for you response, potentially leading to an escalation. For example, it is triggering that you imply that I "eschew versioning", when I believe to have thought deeply about versioning for quite a few years now. That's not meant as a criticism but as an example. This paragraph is another example; it would be better for me to swallow my pride and silently ignore such statements. Doing that in private, is easier, than when speaking to a wider audience.

[progfolio]

Nicholas, I have the deepest respect for you and you work, and I hope it is fair to assume you feel similarly about my work.

Yes, the respect is mutual. My apologies if I've given any other impression.
Magit is a tool I use daily, which has had a positive impact on my work.

We do have some fundamental disagreements on some important technical matters, but that is fine, such things happen. It is more important to preserve a good working relation than to resolve all disagreements.

That being said, I think we might be able to work something out. We should at least try. I would like to do this privately over email, and will send a first message soon, hopefully within a few days.

I think it is better to do it privately than, e.g., in response to a pull-request like this, "there is a minor defect in your package, which can can trivially be fixed like so". That puts me on the defensive, which results in me leaning towards slightly more snarky/unyielding/... wording than necessary/productive. Which in turn sets the mood for you response, potentially leading to an escalation. For example, it is triggering that you imply that I "eschew versioning", when I believe to have thought deeply about versioning for quite a few years now. That's not meant as a criticism but as an example. This paragraph is another example; it would be better for me to swallow my pride and silently ignore such statements. Doing that in private, is easier, than when speaking to a wider audience.

Agreed. Feel free to reach out: [email protected]
I look forward to collaborating with you.

[tarsius]

Yes, the respect is mutual. My apologies if I've given any other impression.

No worries, I wasn't under the impression that this was not so.
Until soon(ish)!