Closed josephmturner closed 1 week ago
I understand the desire, but I'm trying to be very strict about version numbers and forcing users to upgrade packages that don't have to be upgraded. The version numbers are, to me, a form of communicating to the users and downstream maintainers, as well. So if I forced that upgrade to happen, while it might prevent that compilation warning from happening, it could create extra work for others, which I want to avoid. They can always upgrade taxy
whenever they feel like it, if they see it in the list of upgradable packages.
hyperdrive.el
already depends on taxy-magit-section
v0.14
. Should hyperdrive.el
add taxy
v0.10.2
as an explicit dependency?
IMHO, no, because the bug that is fixed is "merely" a warning at compilation time, and I don't think that justifies forcing a user to upgrade. (e.g. in my config, I commit installed packages to git, so having a forced library upgrade makes more churn in my git repo that I have to deal with.) But you are the maintainer of hyperdrive
, so it is up to you. :)
Okay, thank you!
This commit, released as part of
taxy
v0.10.2
, fixed an issue with macroexpanded docstring width being too long. This commit, released as part oftaxy-magit-section
v0.14
, fixed a different issue of the same kind.I think
taxy-magit-section
should depend on the latest version oftaxy
(v0.10.2
) so that users can install justtaxy-magit-section
and be sure to avoid the bug.(In our testing in your VM and in the automated builds, I think the issue didn't show up because we're always installing the
hyperdrive.el
dependencies from scratch. However, my machine still has an old copy oftaxy
v0.10.1
on it, and so the compilation warning still shows up.)