[Felix]
I was referring to the next minor version.
OK. If as you're proposing in the MR this gets
integrated in Homebrew via a fast path rather
than a release on our side, everyody's happy.
[Lukas]
[Jean]
What kind of next version, next minor of
current stable, i.e. 2.22.2, or next
stable release, 2.24?
Which leads me to ask:
@Jefferson: Would it be conceivable to do Homebrew builds also for
(odd-numbered) development versions of LilyPond? LilyPond tends to
have a conservative policy regarding stable releases (although the six
year hiatus between 2.18.2 in March 2014 and 2.20.0 in March 2020
might be considered extreme even by LilyPond's standards). But at the
same time, LilyPond development procedures make sure that today,
Master never really breaks: Every patch in master gets a thorough
review and, equally important, is tested against an extensive suite of
regression tests. Because of this, LilyPond master is kept always in a
working condition, and the development releases (which are cut from
git master from time to time) can be expected to (although they are
not guaranteed to) allow production-quality work. In fact, many
LilyPond users routinely use the development versions, as they are the
only option (short of do-it-yourself building) to make use of new
features in the often long time between stable releases. So if it
would be possible to do not only a "lilypond" package but also a (more
frequently updated) "lilypond-devel" package, this would match the use
practice of many LilyPond users even better.
Agreed. If you do this, be sure to ship bytecode.
Not only does it eliminate the startup overhead
and bring better overall performance, but I guess
you wouldn't want the compilation to trigger on the
first run if the user happens to have
GUILE_AUTO_COMPILE=1 in their environment.
As for the underlying question, I think a modified version message if
LilyPond is running Guile2 (or Guile3, for that matter) would be
enough. (And I agree with J.F. that this message should only mention
Guile, not Homebrew.)
This has become
https://gitlab.com/lilypond/lilypond/-/merge_requests/950
If I understand Jonas's remark correctly, it should make no difference
if this is done at compile time via C++ #ifdef GUILEV2 (as in Jean's
proposal) or at runtime via Scheme cond-expand, right?
Right. The tight link between LilyPond and
its Scheme interpreter is established at
compile time.
Best,
Jean
