From: Philip Kaludercic <philipk@posteo.net>
To: Stefan Kangas <stefankangas@gmail.com>
Cc: iarchivedmywholelife@gmail.com, joseph@breatheoutbreathe.in,
69528@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
Andrea Corallo <acorallo@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca>
Subject: bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions
Date: Sun, 02 Jun 2024 11:07:02 +0000 [thread overview]
Message-ID: <871q5ffvs9.fsf@posteo.net> (raw)
In-Reply-To: <CADwFkmn4S5ocBUYc5mKee1c38BBSVKLaWGbDBPYGWPpP4Rhwqw@mail.gmail.com> (Stefan Kangas's message of "Sun, 2 Jun 2024 10:36:26 +0000")
Stefan Kangas <stefankangas@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> > What about making `lm-version' handle the "package-version" header then
>>> > using `lm-version' in loaddefs-generate--parse-file? See patches.
>>>
>>> My main concern was if we want to have Package-Version always override
>>> Version, but if my patch modified loaddefs-gen, then I don't think there
>>> is much of a difference if we change lisp-mnt instead (in terms of the
>>> generality of the change).
>>>
>>> So I am fine with the change, and think we can merge it. Eli: Is master
>>> still fine for these kinds of changes?
>>
>> I think so, yes. But maybe I don't fully understand the effect of
>> this change? Can you describe it?
Sorry for the late response, but Stefan summaries the situation well
below.
>> I also added the other maintainers, in case they have opinions on
>> this.
>
> I think the first patch is right, i.e. to use
>
> (lm-version)
>
> instead of
>
> (lm-header "version")
>
> So let's install that one, I think.
I agree.
> The effect of the second patch is to change `lm-version` to look for a
> "Package-Version" header if there is no "Version" header.
>
> This has two problems:
>
> 1. We didn't do that until now, and it's not clear to me what is the
> issue that is prompting this change. The transient.el issue seems to
> have been fixed already.
>
> 2. The way I read the manual, it seems like "Package-Version" should be
> preferred over "Version", if it exists:
>
> ‘Package-Version’
> If ‘Version’ is not suitable for use by the package manager, then a
> package can define ‘Package-Version’; it will be used instead.
> This is handy if ‘Version’ is an RCS id or something else that
> cannot be parsed by ‘version-to-list’.
>
> I'm also not sure we need to support packages with unusual versions
> like RCS id's these days. Is that use case still relevant? Perhaps
> we should simply deprecate the "Package-Version" header?
FWIW I use this for some of my own scripts that I version using RCS, so
I'd appreciate it if that functionality would stay.
--
Philip Kaludercic on peregrine
next prev parent reply other threads:[~2024-06-02 11:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-03 17:25 bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions No Wayman
2024-03-04 17:22 ` No Wayman
2024-03-04 18:41 ` Philip Kaludercic
2024-03-05 6:17 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-09 6:53 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 7:39 ` Eli Zaretskii
2024-05-25 8:04 ` Philip Kaludercic
2024-05-25 8:08 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 8:47 ` Philip Kaludercic
2024-05-26 0:45 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-05-25 10:49 ` Eli Zaretskii
2024-06-02 10:36 ` Stefan Kangas
2024-06-02 11:07 ` Philip Kaludercic [this message]
2024-06-02 12:08 ` Stefan Kangas
2024-06-02 13:11 ` Philip Kaludercic
2024-06-02 18:26 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-02 18:40 ` Philip Kaludercic
2024-06-03 17:24 ` Stefan Kangas
2024-06-03 19:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-03 19:58 ` Philip Kaludercic
2024-06-03 20:38 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-04 22:19 ` Stefan Kangas
2024-06-04 22:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-06-04 22:22 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871q5ffvs9.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=69528@debbugs.gnu.org \
--cc=acorallo@gnu.org \
--cc=eliz@gnu.org \
--cc=iarchivedmywholelife@gmail.com \
--cc=joseph@breatheoutbreathe.in \
--cc=monnier@iro.umontreal.ca \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.