[bug#63984] [PATCH emacs-team 0/2] Start preparing for Emacs 29

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Am Samstag, dem 10.06.2023 um 12:20 +0400 schrieb Andrew Tropin:
> On 2023-06-10 09:46, Liliana Marie Prikler wrote:
> 
> > Am Samstag, dem 10.06.2023 um 10:46 +0400 schrieb Andrew Tropin:
> > > On 2023-06-09 18:22, Liliana Marie Prikler wrote:
> > > 
> > > > Hi Guix,
> > > > 
> > > > it's already been four weeks since the newest Emacs pre-
> > > > release. 
> > > > Time
> > > > sure flies.  With that in mind, I'd like to start work in the
> > > > Emacs
> > > > team
> > > > focused on
> > > > 1. streamlining our Emacs packages
> > > > 2. improving emacs-build-system and adapting it to the new
> > > > features
> > > > of
> > > >    Emacs 29 (including the almost forgotten [1])
> > > > 3. improving our Emacs package management (i.e. making it
> > > > easier to
> > > >    declare variants of emacs-* packages built with different
> > > > Emacsen)
> > > > 
> > > > This series gets us started on (1), so we can do (2) and (3)
> > > > hopefully
> > > > soon.
> > > > 
> > > > Cheers
> > > > 
> > > > [1] https://issues.guix.gnu.org/57122
> > > > 
> > > > Liliana Marie Prikler (2):
> > > >   gnu: Make emacs-next-tree-sitter the new emacs.
> > > >   gnu: Construct Emacs packages from bottom up.
> > > > 
> > > >  gnu/local.mk                                  |   1 -
> > > >  gnu/packages/emacs.scm                        | 467 +++++++---
> > > > ----
> > > > ----
> > > >  .../patches/emacs-source-date-epoch.patch     |  20 -
> > > >  3 files changed, 190 insertions(+), 298 deletions(-)
> > > >  delete mode 100644 gnu/packages/patches/emacs-source-date-
> > > > epoch.patch
> > > > 
> > > > 
> > > > base-commit: 44bbfc24e4bcc48d0e3343cd3d83452721af8c36
> > > 
> > > Hi Liliana, 
> > > 
> > > the patch series looks good, thank you for working on this.  Do
> > > we want to add (define-deprecated/alias) to make the transition
> > > to new emacs package names smoother?
> > Since it'll be a "world"-rebuilding change, I think a news entry
> > ought to be preferred.
> 
> I don't think one excludes another.  We can provide both news entry
> and deprecation alias.  This way we let people update guix channel
> version without any changes to their configurations, let them know
> emacs-next-blabla will dissapear soon and give them time to react and
> update their configurations accordingly without hurry.
> 
> I'm ok proceeding without this extra step, but the deprecation
> workflow seems nicer to me.
You're right in that one does not exclude the other, but there are
practical limitations.  When emacs itself has version 29, emacs-next
ought to be 30, imho.

Cheers