lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.20 and 2.21 release plans


From: David Kastrup
Subject: Re: 2.20 and 2.21 release plans
Date: Tue, 18 Feb 2020 01:15:42 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> Am Montag, den 17.02.2020, 13:25 +0100 schrieb David Kastrup:
>> Ok, I think 2.20 is basically done and we should push it out by the
>> end
>> of this week.  
>
> This is really great news!
> I'm somewhat undecided whether it is a cause for celebration or not to
> finally release a "stable" version after six years. But at the end of
> the day I think we should praise those who have actually worked so hard
> to make it happen. And all of us who benefit from that work might think
> about what we can do to help bringing the *next* stable release over
> the goal line in less than six years.
>
> I have one side remark to that, although I'm not sure if it's
> appropriate to inject it into this thread.
>
> I haven't commented on the issue of a package loading mechanism
> recently, for two reasons: I don't have any time right now, and I
> thought it would be a distraction from the more pressing issues around
> the build system, contribution workflow/tooling and finalizing a
> release.
> While it has been clear from the start that integrating a package
> loading mechanism was not in question for 2.20.0, I would like to ask
> if it can be considered making this go into a 2.20.x release and not
> keep it on the 2.21 track as would be the natural itinerary. Doing so
> (the latter) would force openLilyLib and - more importantly -
> interfaces like Frescobaldi to support two alternative syntaxes of
> loading packages until a 2.22 release.
> So I would be glad if we could spend sufficient effort after 2.20.0 and
> 2.21.0 releases to discussing, implementing, and testing a package
> loading mechansim sufficiently that we can integrate it not only in the
> 2.21.x but also a 2.20.x release.

I don't think that would make a lot of sense since 2.21.x is the test
and maturing bed for 2.22.

But there is nobody forcing us to take 6 years for 2.22.  Or 3.0.  A
fully functional package organisation system would in my opinion justify
a major version number change.  Also it does look like the next stable
release is going to contain Guile 2+ support that is less of an
abomination than what we have so far been able to provide.

At any rate, I don't think it makes sense to nail down too many
specifics of unreleased versions.  Not if we want to end up more timely
than this time round.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]