Re: Thinking about the next stable release

[Jonas Hahnfeld]

On Sun, 2022-05-22 at 17:04 +0200, David Kastrup wrote:
> We aren't talking about "switching" but "supporting".  It is the
> business of the distribution makers to decide which version to ship, and
> particularly if they are not thorough users of some software themselves,
> they'll tend to select "latest stable" for their latest stable releases.
> 
> We want to get out of the "won't ship LilyPond because it requires
> legacy versions of Guile which cause a lot of extra work to support"
> trap.
> 
> > If people assume "works with Guile 3.0.x" and think the latest patch
> > release is the best, as is usual, we're in trouble on the day a Guile
> > 3.0.x release comes that breaks us.
> 
> No, Guile is in trouble then.  I mean, it is in trouble now.  But if
> distributors can easily do version-hopping on their own initiative and
> end up with one version of Guile they are going to ship for their whole
> distro, it would be good if that does not end up in making LilyPond
> disappear.  That's all.
> 
> What we _recommend_ and use ourselves is an entirely different matter.

I agree with all this, getting away from legacy Guile 1.8 was exactly
my point of thinking about a stable release. And as Jean has already
pointed out, current master should work with Guile 3.0 if you ask
configure nicely about it. What needs discussion is really the last
point: Do we recommend using it with Guile 3.0 (and make configure look
for it)? Should it take precedence over Guile 2.2 if both are found? Or
do we just make it "possible" to build with other versions of Guile,
much the same that it's possible to build stable/2.22 with Guile 2.2?
But for me, that's really a second discussion that does not (for me)
influence the decision about *if* we aim for a stable release.

signature.asc
Description: This is a digitally signed message part