all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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





  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.