Jonas Hahnfeld via Discussions on LilyPond development <lilypond-devel@gnu.org> writes:
> The reason I'm explicitly looking at Debian is that they currently > bundle Guile 1.8 in their package, which also serves as the basis for > Ubuntu's package. I'm sure they would be more than happy to get rid of > that 😉 Once it is bundled, it isn't all that maintenance-heavy. You'd probably need to update with the 1.8 branch tip of Guile maintained by Thien-Thi Nguyen (and/or report if it doesn't compile any more with up-to-date Texinfo/GCC/whatever). Getting it in certainly was quite a bit of work. Getting it out and redepending with Guile-2.2 will be more work. Particularly since the current version of Guile isn't 2.2 any more. > So, what do people think: Would targeting a release towards the end of > this year be a reasonable thing? I think we should aim to have any new stable release work with _current_ Guile versions. If we are going to replace a dependency on one outdated version of Guile with one of another outdated version, people will be rightfully mad at us. > If yes, there was some discussion in the past to make the release > after that a new major version to enable bigger changes, such as > potentially switching to Cairo. This would probably require removing > some things, such as the \postscript command, that we should properly > deprecate one stable release in advance... So the choices are: > > 0) Too early for a stable release, ok to miss the next Debian version. > 1) Target a release towards the end of this year, but do not deprecate > things in anticipation of a new major version after; instead go for a > "regular" 2.26.0 afterwards. > 2) Target a release towards the end of this year and deprecate things > that we want to remove in LilyPond 3.0 (the details should be discussed > in a separate thread, I think) I am sort of fuzzy on the plans because my own plans tend not to work out well enough to coordinate them with other software releases. -- David Kastrup
