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.

-- 
Best regards,
Andrew Tropin