From: Suhail Singh <suhailsingh247@gmail.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: "Suhail Singh" <suhailsingh247@gmail.com>,
"Martin Edström" <meedstrom@runbox.eu>,
emacs-devel <emacs-devel@gnu.org>,
"Tony Zorman" <tonyzorman@mailbox.org>
Subject: Re: Reconsider defaults for use-package-vc-prefer-newest
Date: Sat, 21 Sep 2024 15:04:21 -0400 [thread overview]
Message-ID: <87tte8akwa.fsf@gmail.com> (raw)
In-Reply-To: <87settknf1.fsf@posteo.net> (Philip Kaludercic's message of "Sat, 21 Sep 2024 15:59:46 +0000")
Philip Kaludercic <philipk@posteo.net> writes:
>>> I wonder if indicating a "commit mismatch" for remote packages might
>>> be interesting (we explicitly don't want this for local packages,
>>> e.g. packages installed via package-vc).
>>
>> Depending on the logic of "commit mismatch" detection, that may be
>> sufficient. Could you describe what you had in mind?
>
> In your case/the case of julia-mode, something like
>
> Other versions: 1.2.3 (melpa-stable, COMMIT MISMATCH).
>
> with a help annotation.
Yes, something like that would have worked. Thanks in advance, if you
do implement something of that nature. It would be useful.
>>> Could you perhaps elaborate on why you consider this to be a bug?
>>
>> To be clear I meant that it's a bug in the remote package.
>
> Perhaps I am being pedantic, but this sounds like a mistake, not a /bug/
> in the code itself.
I meant that I considered it a software defect in the packaging process.
It might have been more accurate to term it a bug in the remote
package's packaging process. In any case, the implication wasn't that
it was a bug in the remote package's source code. I hope it's clearer
now.
>> Specifically, in the case of julia-mode, it was a bug for it to have
>> introduced the 0.4 package header in a commit that was different from
>> the one that was tagged as 0.4.
>
> Do you know which of the two is correct? In cases like these, it sounds
> like one should contact the maintainers to remind them that they
> shouldn't repeat the same issue in the future.
Given that the change that was added between the commit that updated the
package header and the commit that corresponded to the git tag was a
fairly important bug-fix, I believe the intended revision (for 0.4) was
the one corresponding to the git tag (i.e., the more recent commit and
the one available via melpa-stable).
In general, for packages with a git repository that have a presence
outside of GNU and NonGNU ELPA, I believe the version corresponding to
the "git tag" to be more closely aligned with the maintainer's intent.
That being said, however, based on a recent exchange, the recommended
version that the maintainer of julia-mode wishes users download is the
"rolling release" equivalent from melpa. I believe it is for this
reason that they have not made a tagged release in the last four years.
Quoting below the maintainer's response on the issue ([1]) where I
brought this matter to their attention:
#+begin_quote
Since we do not make stable releases (effectively, it is just rolling on
`master`, I think we should just clarify that users should use `melpa`, and if
possible expunge the package from `melpa-stable` etc.
#+end_quote
[1]: <https://github.com/JuliaEditorSupport/julia-emacs/issues/212#issuecomment-2328150198>
--
Suhail
next prev parent reply other threads:[~2024-09-21 19:04 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-14 12:09 Reconsider defaults for use-package-vc-prefer-newest Martin Edström
2024-09-19 11:49 ` Philip Kaludercic
2024-09-19 18:50 ` Suhail Singh
2024-09-19 20:11 ` Philip Kaludercic
2024-09-19 20:31 ` Philip Kaludercic
2024-09-20 6:15 ` Eli Zaretskii
2024-09-20 15:14 ` Philip Kaludercic
2024-09-20 15:45 ` Eli Zaretskii
2024-09-20 16:56 ` Philip Kaludercic
2024-09-20 17:37 ` Eli Zaretskii
2024-09-20 20:43 ` Philip Kaludercic
2024-09-21 7:14 ` Eli Zaretskii
2024-09-21 14:31 ` Philip Kaludercic
2024-09-21 15:18 ` Eli Zaretskii
2024-09-21 15:43 ` Philip Kaludercic
2024-09-19 21:02 ` Suhail Singh
2024-09-20 20:34 ` Philip Kaludercic
2024-09-20 23:38 ` Suhail Singh
2024-09-21 7:06 ` chad
2024-09-21 14:27 ` Suhail Singh
2024-09-21 15:59 ` Philip Kaludercic
2024-09-21 19:04 ` Suhail Singh [this message]
2024-09-22 15:30 ` Philip Kaludercic
2024-09-22 20:08 ` Suhail Singh
2024-09-25 12:06 ` Suhail Singh
2024-09-25 13:15 ` Philip Kaludercic
2024-09-25 12:07 ` Philip Kaludercic
2024-09-25 15:15 ` Suhail Singh
2024-09-25 20:11 ` Philip Kaludercic
2024-09-25 20:48 ` Suhail Singh
2024-09-29 2:13 ` Richard Stallman
2024-09-29 7:25 ` Philip Kaludercic
2024-09-29 13:55 ` Suhail Singh
2024-09-26 23:23 ` Charles Choi
2024-09-27 0:17 ` Adam Porter
2024-09-27 0:33 ` Suhail Singh
2024-09-27 6:46 ` Eli Zaretskii
2024-09-29 14:22 ` Stefan Kangas
2024-09-29 14:35 ` Eli Zaretskii
2024-10-11 18:54 ` Suhail Singh
2024-10-12 5:46 ` Eli Zaretskii
2024-09-20 4:57 ` Tony Zorman
2024-09-20 19:37 ` Martin Edström
2024-09-20 21:05 ` Philip Kaludercic
2024-09-21 14:44 ` Philip Kaludercic
2024-09-21 14:58 ` Tony Zorman
2024-09-21 15:10 ` Suhail Singh
2024-09-21 16:09 ` Philip Kaludercic
-- strict thread matches above, loose matches on Subject: below --
2024-09-15 17:38 Martin Edström
2024-09-15 18:24 ` Eli Zaretskii
2024-09-15 19:46 ` Martin Edstrom
2024-09-16 11:34 ` Eli Zaretskii
2024-09-16 15:24 ` Martin Edström
2024-09-16 16:15 ` Martin Edström
2024-09-16 17:57 ` Eli Zaretskii
2024-09-18 14:30 ` Martin Edström
2024-09-15 19:52 Martin Edström
2024-09-15 20:41 ` chad
2024-09-15 21:09 ` Martin Edstrom
2024-09-15 22:12 ` chad
2024-09-15 23:51 ` Martin Edstrom
2024-09-16 11:50 ` Eli Zaretskii
2024-09-16 16:46 ` Martin Edström
2024-09-16 18:10 ` Eli Zaretskii
2024-09-16 20:16 ` Suhail Singh
2024-09-17 11:44 ` Eli Zaretskii
2024-09-19 3:38 ` Suhail Singh
2024-09-19 6:28 ` Eli Zaretskii
2024-09-19 12:08 ` Suhail Singh
2024-09-19 12:39 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tte8akwa.fsf@gmail.com \
--to=suhailsingh247@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=meedstrom@runbox.eu \
--cc=philipk@posteo.net \
--cc=tonyzorman@mailbox.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).