Subject: bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions

From: Stefan Kangas <[email-masked]>
Date: Sun, 2 Jun 2024 10:36:26 +0000

Eli Zaretskii <[email-masked]> 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?
>
> 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.

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?