> Would it be conceivable to do Homebrew builds also for (odd-numbered) development versions of LilyPond?
According to homebrew rules, only stable versions are accepted. And really, there is no * -devel package in the homebrew repository. About that, I believe we can patch the formula until the next stable version is released. However, there is a build from HEAD option (`brew --HEAD`), which is even being implemented in lilypond formula ( https://github.com/Homebrew/homebrew-core/pull/86490). Em ter., 5 de out. de 2021 às 18:20, Lukas-Fabian Moser <l...@gmx.de> escreveu: > [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. > > 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.) 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? > > Lukas > -- --- Jefferson dos Santos Felix
