Re: Thinking about the next stable release

[David Kastrup]

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