Re: Two questions regarding the :core workflow

[J.P.]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  1. I'm thinking ERC could benefit from suffixing our future version
>>     numbers on HEAD with "snapshot" or "-git" [1]. This might be helpful
>>     for things like bug reports, protocol transcripts, and certain
>>     in-band messages, such as /CTCP VERSION replies. Trying this out
>>     locally seems to succeed in only building a devel package and
>>     skipping a release. Any reason the same wouldn't happen on the
>>     production instance?
>
> Can't think of any reason why it wouldn't work the same, no.
>
>>  2. I've been wondering about the :core workflow when it comes to
>>     patching ERC releases and iterating on HEAD. I see that "external"
>>     packages can specify a separate :release-branch. Assuming such a
>>     thing isn't possible for :core packages, ERC would seem to enter a
>>     sort of "limbo period" come every (Emacs) release season, during
>>     which we're obliged to hold off on applying major changes to HEAD
>>     until the next release, like 29.1, has been out long enough for any
>>     glaring bugs to emerge. To be clear, this isn't me complaining (ERC
>>     has plenty else to concern itself with during such spells). But, in
>>     the interest of planning ahead, I'd like to know if this perceived
>>     limbo period is a real thing or yet another unfounded hallucination.
>
> It's true that `:core` can't be combined with `:release-branch`
> currently.  Maybe it could be fixed, but IIRC it's somewhat risky (it's
> likely to fall into some of the problems that have occasionally caused
> the state on `elpa.gnu.org` to become weird, preventing the release of
> new tarballs until I log in manually and unwedge the thing).
> So it's better not to rely on it.
>
> I don't think it implies that there's a strong interaction between Emacs
> releases and ERC releses.  The only "limbo period" is when you're asked
> not to commit destabilizing changes to `master` when we're about to cut
> a new release branch, and this tends to be shortish.  Once the branch is
> cut, you can keep making changes on `master` to your heart's content,
> more or less, while Emacs's release matures on the branch, is released,
> and even while subsequent point releases are made.
>
> It does mean that you can't make wild changes to ERC as long as there's
> a chance you need to make a new ELPA release based on the old code.

Right, this was my chief concern. But I can see that wanting to keep
both doors open indefinitely amounts to having our cake and eating it
too ("millennial entitlement on full display" being my official excuse).

> But you can have wild changes on `master` while at the same time
> installing small fixes on the `emacs-29` branch (you just won't able to
> make a corresponding stable release ELPA tarball).

Somewhere along the line, I must have convinced myself that preserving a
correspondence was a priority, but I've come to terms with regarding
such thinking as delusional. At the very least, it places an artificial
constraint on the pace of development because no matter how conservative
we pretend to be, we'll surely encounter an urgent enough fix to warrant
a betrayal. And sticking to our guns could only mean temporarily
reverting wilder changes in order to induce an emergency patch release
(e.g. 5.5, 5.6-git, 5.5.1, 5.6-git, ..., 5.6), which would never be
tolerated given all the logs/blame pollution it'd surely cause.

In the end, I think ERC will need to tighten its release cycle and save
its wildest changes for a feature branch or at least arrange for their
application extra judiciously.

> Does that clarify the situation?

Very much so. Thanks.