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

[Andrew Tropin <andrew@trop.in>]

[-- Attachment #1: Type: text/plain, Size: 3336 bytes --]

On 2023-06-10 10:51, Liliana Marie Prikler wrote:

> 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.

Sounds reasonable, but I think it would be ok, if after updating emacs,
emacs-next will be 29 for a couple of weeks with deprecation warning on
top of it.  The meaning of -next suffix is a convention, not a technical
limitation, so it's fine to violate it for deprecation period.

Overall, deprecation is not something crucial here and people know that
guix breaks backward compatibility from time to time, so I think it's ok
to go without it.

-- 
Best regards,
Andrew Tropin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]