From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: dmitry@gutov.dev, joaotavora@gmail.com, emacs-devel@gnu.org
Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)
Date: Tue, 18 Apr 2023 12:36:12 -0700 [thread overview]
Message-ID: <93acbd4d-442f-b0a8-4476-44a76a1267d7@gmail.com> (raw)
In-Reply-To: <83ildt808j.fsf@gnu.org>
On 4/18/2023 12:21 PM, Eli Zaretskii wrote:
>> Date: Tue, 18 Apr 2023 11:56:58 -0700
>> Cc: joaotavora@gmail.com, emacs-devel@gnu.org
>> From: Jim Porter <jporterbugs@gmail.com>
>>
>> It sounds to me like there are 3 or 4 levels (depending on how you count):
>>
>> * Stable: the version of a package included in the latest Emacs tarball
>> * Latest: the latest version on GNU ELPA (etc)
>> * Devel: the latest version on GNU-devel ELPA (etc)
>
> I think we need only two. Stable can move to the next version, since
> packages are released more frequently than Emacs.
At least from a user POV, I think it makes sense to distinguish among
all three of these. For example, I might use the version of Eglot in
Emacs 29, or I might install it from GNU ELPA, or I could even install
it from GNU-devel ELPA. I might even switch back and forth depending on
what my needs are (and in fact, that's exactly what I do with Eglot;
while I usually prefer to stick on the GNU ELPA version, sometimes I
switch to GNU-devel ELPA if there's a fix for a bug I find very bothersome).
I think this set of three levels also makes it easier - at least for me
- to reason about what to do with something like ElDoc. If a user
installs Eglot from GNU ELPA (i.e. the user gets "Eglot latest"), should
it automatically install ElDoc from GNU ELPA ("ElDoc latest") or should
it use the ElDoc from the Emacs tarball ("ElDoc stable")?
If there were only two levels - latest and devel - then I think the
answer to the Eglot/ElDoc problem would simply be: installing Eglot
latest should pull in ElDoc latest. Since there's no higher "stability
gradation" than latest, we wouldn't really be able to say that
ElDoc-from-Emacs is better/stabler than ElDoc-from-ELPA. (Well, we can
still *say* that, but I think it helps to embed our reasoning for it
into these stability gradations.)
> How is this different from what we have in Emacs? An exciting new
> feature is sometimes deferred to the next major release if the release
> branch is close enough to a release. There's nothing new here, just
> the fact that sometimes useful new features could destabilize Emacs,
> so one needs to choose which one it wants more.
I think the main difference is that Eglot and Emacs (and ElDoc, for that
matter) all have different release cadences, so it would be helpful to
have some functionality to help us manage that. With Emacs itself, we
can ensure that every package that ships in the tarball is works well
with each other; when we distribute a package on ELPA, this gets trickier.
>> One alternative would be for packages to be able to *recommend*
>> dependencies. Then, Eglot could recommend newer versions of ElDoc, but
>> they wouldn't actually be required.
>
> This is probably needed, but it requires non-trivial support from
> package.el, to let informed users select the updates that fit their
> stability requirements and feature needs.
Yeah, that's where this gets tricky for Emacs 29: it's probably a bit
late to add major new features like this to package.el for 29. However,
we might be able to accept an imperfect solution for Eglot today while
working to provide a better way for Emacs 30.
next prev parent reply other threads:[~2023-04-18 19:36 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87a5zj2vfo.fsf@gmail.com>
[not found] ` <83wn2h5825.fsf@gnu.org>
[not found] ` <87wn2gkhzr.fsf@posteo.net>
[not found] ` <83cz485oxi.fsf@gnu.org>
[not found] ` <87leiwdyff.fsf@posteo.net>
[not found] ` <834jpk5hih.fsf@gnu.org>
[not found] ` <871qkom3fj.fsf@posteo.net>
[not found] ` <83mt3b4yfc.fsf@gnu.org>
[not found] ` <87edonlsxi.fsf@posteo.net>
[not found] ` <83jzyf4vzb.fsf@gnu.org>
[not found] ` <871qknllkj.fsf@posteo.net>
[not found] ` <83fs934pjf.fsf@gnu.org>
[not found] ` <87wn2fk47y.fsf@posteo.net>
[not found] ` <83sfd2g2ek.fsf@gnu.org>
[not found] ` <875y9yfxrr.fsf@gmail.com>
[not found] ` <CALDnm50-Su4SAGDSBiLjt0yrjrVsvyW71NSMi=zt7uHgv7rdng@mail.gmail.com>
[not found] ` <87y1muefks.fsf@gmail.com>
[not found] ` <CALDnm50b6hRu+4EFqQDVydOF07HdiZT4nHA=aLDjYQKtMBTk2Q@mail.gmail.com>
[not found] ` <fc2ed4a0-2368-682d-e34d-5cf94ac261fc@gutov.dev>
[not found] ` <CALDnm527Avsa-MBTD-bvRqOn52AeBLfPvffxjL-NB3tqM=43ZQ@mail.gmail.com>
[not found] ` <834jpifizy.fsf@gnu.org>
[not found] ` <CALDnm53X5Yyn_EitG+iHJVx=RO2hjNaWkrgPz0+jKVWVM=eEBQ@mail.gmail.com>
[not found] ` <83y1mue1qi.fsf@gnu.org>
[not found] ` <CALDnm51hmRMxstQdZdstA2LrbvYw=zD5=XRVy6uCU=Z+OmONRg@mail.gmail.com>
[not found] ` <83sfd2e01f.fsf@gnu.org>
[not found] ` <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev>
[not found] ` <83sfcz9rf2.fsf@gnu.org>
[not found] ` <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev>
2023-04-18 12:57 ` Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Eli Zaretskii
2023-04-18 14:02 ` João Távora
2023-04-18 14:47 ` Eli Zaretskii
2023-04-18 15:45 ` João Távora
2023-04-18 16:19 ` Eli Zaretskii
2023-04-18 17:49 ` João Távora
2023-04-18 21:19 ` Dmitry Gutov
2023-04-18 18:56 ` Jim Porter
2023-04-18 19:21 ` Eli Zaretskii
2023-04-18 19:36 ` Jim Porter [this message]
2023-04-19 11:55 ` Eli Zaretskii
2023-04-19 8:50 ` João Távora
2023-04-19 12:13 ` Dr. Arne Babenhauserheide
2023-04-19 17:03 ` Eli Zaretskii
2023-04-19 17:21 ` João Távora
2023-04-19 18:07 ` Eli Zaretskii
2023-04-19 18:14 ` Dmitry Gutov
2023-04-19 18:32 ` Eli Zaretskii
2023-04-19 19:33 ` João Távora
2023-04-20 4:26 ` tomas
2023-04-19 19:39 ` Dmitry Gutov
2023-04-19 19:46 ` João Távora
2023-04-19 20:50 ` Dmitry Gutov
2023-04-19 20:57 ` João Távora
2023-04-19 21:58 ` Jim Porter
2023-04-19 22:29 ` João Távora
2023-04-19 22:42 ` Jim Porter
2023-04-19 22:58 ` João Távora
2023-04-19 22:06 ` Dmitry Gutov
2023-04-19 22:21 ` Jim Porter
2023-04-19 22:27 ` Dmitry Gutov
2023-04-19 22:43 ` Jim Porter
[not found] ` <f32d7008-ea39-a9d7-8224-2c5b969236b7@gutov.dev>
[not found] ` <CALDnm53vPnODxpv_=nvOHRjLX-PfhyTS0MFudR0qZ3Pa-Lw-AQ@mail.gmail.com>
2023-04-19 23:25 ` Dmitry Gutov
2023-04-20 0:13 ` João Távora
2023-04-20 1:13 ` Dmitry Gutov
2023-04-20 1:49 ` João Távora
2023-04-20 2:04 ` Dmitry Gutov
2023-04-19 19:15 ` João Távora
2023-04-20 9:38 ` Eli Zaretskii
2023-04-20 9:48 ` João Távora
2023-04-20 11:47 ` Eli Zaretskii
2023-04-20 12:00 ` João Távora
2023-04-20 12:16 ` Eli Zaretskii
2023-04-20 12:24 ` João Távora
2023-04-19 17:35 ` John Yates
2023-04-19 17:42 ` João Távora
2023-04-19 18:02 ` Eli Zaretskii
2023-04-19 18:04 ` Jim Porter
2023-04-19 18:34 ` Eli Zaretskii
2023-04-19 19:35 ` Jim Porter
2023-04-20 9:49 ` Eli Zaretskii
2023-04-19 19:40 ` Dr. Arne Babenhauserheide
2023-04-20 6:02 ` Eli Zaretskii
2023-04-29 5:21 ` Stability of core packages emacs
2023-04-29 6:26 ` Eli Zaretskii
2023-04-29 21:47 ` Mohsen BANAN
2023-04-30 6:21 ` Eli Zaretskii
2023-04-30 9:07 ` Philip Kaludercic
2023-04-30 13:12 ` Corwin Brust
2023-05-07 5:58 ` Mohsen BANAN
2023-05-05 4:36 ` David Masterson
2023-05-05 4:56 ` David Masterson
[not found] ` <878re3bdj6.fsf@penguin>
2023-05-05 4:59 ` David Masterson
2023-04-19 12:55 ` Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Eli Zaretskii
2023-04-19 13:18 ` João Távora
2023-04-19 13:44 ` Eli Zaretskii
2023-04-19 14:13 ` João Távora
2023-04-18 22:10 ` Dmitry Gutov
2023-04-19 8:34 ` João Távora
2023-04-19 12:47 ` Eli Zaretskii
2023-04-19 18:22 ` Jim Porter
2023-04-19 18:37 ` Eli Zaretskii
2023-04-19 19:32 ` Jim Porter
2023-04-19 22:51 ` Lynn Winebarger
2023-04-20 13:47 ` history of ELPA packages and dependencies (was: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)) Lynn Winebarger
2023-04-20 13:58 ` Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Lynn Winebarger
2023-04-19 19:25 ` Dmitry Gutov
2023-04-19 19:40 ` João Távora
2023-04-20 9:47 ` Eli Zaretskii
2023-04-20 13:03 ` Dmitry Gutov
2023-04-20 14:03 ` Eli Zaretskii
2023-04-20 14:22 ` Dmitry Gutov
2023-04-20 14:42 ` Eli Zaretskii
2023-04-20 15:30 ` Dmitry Gutov
2023-04-20 15:49 ` Eli Zaretskii
2023-04-20 17:26 ` Stability of core packages Philip Kaludercic
2023-04-20 18:46 ` Eli Zaretskii
2023-04-20 21:25 ` Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Dmitry Gutov
2023-04-21 14:12 ` Lynn Winebarger
2023-04-19 12:31 ` What is :core? (was: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot)) Lynn Winebarger
2023-04-19 12:57 ` João Távora
2023-04-19 13:03 ` 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=93acbd4d-442f-b0a8-4476-44a76a1267d7@gmail.com \
--to=jporterbugs@gmail.com \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=joaotavora@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 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).