lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Moving most initialization to .scm files


From: Thomas Morley
Subject: Re: Moving most initialization to .scm files
Date: Mon, 5 Sep 2022 21:52:25 +0200

Am Mo., 5. Sept. 2022 um 21:34 Uhr schrieb Jonas Hahnfeld <hahnjo@hahnjo.de>:
>
> On Mon, 2022-09-05 at 21:22 +0200, Thomas Morley wrote:
> > Am Mo., 5. Sept. 2022 um 19:50 Uhr schrieb Jonas Hahnfeld via
> > Discussions on LilyPond development <lilypond-devel@gnu.org>:
> > >
> > > On Sun, 2022-09-04 at 22:38 +0200, Jean Abou Samra wrote:
> > > > This needs to be done for lots of code in lots of files, so it will be
> > > > quite a major change to the source even though it is just a 
> > > > straightforward
> > > > translation.
> > >
> > > I don't like this idea very much just two weeks before branching for a
> > > new stable release. No matter how "straightforward", I find the risk
> > > too high that something goes wrong, or that it turns out not to be a
> > > good idea for some other reason, or that we still find it insufficient
> > > and an entirely different solution is required...
> > >
> > > For me, this also means we should go without !1510 for the release.
> > > It's unfortunate, but not the end of the world; and I personally think
> > > it's worse to delay the entire release by weeks / months or even an
> > > undetermined amount of time.
> > >
> > > Jonas
> >
> > I think a stable release without meaningful error-messages as promised
> > by !1510 is unusable for power-users.
>
> So we've had this discussion before:

Indeed

> If I follow the logic, we must not
> have a stable release until the error messages are equally good /
> better than they have been before. This problem has been known for two
> years, with very little activity before Jean started working on it in
> May (?). What I want to avoid is blocking the release for two more
> years. (probably / hopefully exaggerating, but it *will* change the
> schedule)

Well, one could argue the current 2.23.12 without !1510 is as unusable
as a new stable without !1510
Thus no need to postpone 2.24.

For large scheme codings one can just go the route described above.
Maybe document/recommend it somewhere? Not sure, though...

Cheers,
  Harm



reply via email to

[Prev in Thread] Current Thread [Next in Thread]