Hello,
Here is the current patch countdown list. The next countdown will be on
September 13th.
A list of all merge requests can be found here:
https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority
Push:
!387 doc: remove timestamp from HTML output - Han-Wen Nienhuys
I can't work out whether there was consensus on the next released build.
Are we going with 2.21.6 and a release announcement that this is an initial
pre-release for a new stable 2.22.0? Or perhaps go for 2.21.80 as a clearer
sign that it's a pre-release?
--
Phil Holmes
Am Freitag, den 11.09.2020, 12:20 +0100 schrieb Phil Holmes:
> I can't work out whether there was consensus on the next released build.
With nobody else replying, I wouldn't call it consensus.
> Are we going with 2.21.6 and a release announcement that this is an initial
> pre-release for a new s
Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
> > Here is my proposal for how to go ahead:
> >
> > * we build a 2.21.6 from master, and announce it widely as a 2.22
> > pre-release version.
>
> Adding Phil. I di
Jonas Hahnfeld writes:
> Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
>> > Here is my proposal for how to go ahead:
>> >
>> > * we build a 2.21.6 from master, and announce it widely as a 2.22
>> > pre-release
> I don't see that in the current stage of upheaval of both internals and
> build system and infrastructure, there is a point in freezing off some
> half-baked intermediate state that hasn't seen significant exposure to
> extensive testing.
+1 It's too early IMHO. Let's wait at laest a month.
On 11/09/2020 15:22, David Kastrup wrote:
Jonas Hahnfeld writes:
Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
Here is my proposal for how to go ahead:
* we build a 2.21.6 from master, and announce it widely
Am Freitag, den 11.09.2020, 17:14 +0200 schrieb Werner LEMBERG:
> > I don't see that in the current stage of upheaval of both internals and
> > build system and infrastructure, there is a point in freezing off some
> > half-baked intermediate state that hasn't seen significant exposure to
> > exten
Am Freitag, den 11.09.2020, 16:18 +0100 schrieb James Lowe:
> On 11/09/2020 15:22, David Kastrup wrote:
> > Jonas Hahnfeld writes:
> >
> > > Am Sonntag, den 06.09.2020, 13:40 +0200 schrieb Jonas Hahnfeld:
> > > > Am Sonntag, den 06.09.2020, 12:33 +0200 schrieb Han-Wen Nienhuys:
> > > > > Here is
>> > I don't see that in the current stage of upheaval of both
>> > internals and build system and infrastructure, there is a point
>> > in freezing off some half-baked intermediate state that hasn't
>> > seen significant exposure to extensive testing.
>>
>> +1 It's too early IMHO. Let's wait
>> This is not my proposal anymore to just branch, but Han-Wen's idea
>> of having a freeze of 3-4 weeks before branching.
>
> For me, a freeze can only start if we agree that nothing fundamental
> has to be changed or added. IMHO, we are far away from such a
> state.
What we can start, howeve
On Fri, Sep 11, 2020 at 7:08 PM Werner LEMBERG wrote:
>
>
> >> > I don't see that in the current stage of upheaval of both
> >> > internals and build system and infrastructure, there is a point
> >> > in freezing off some half-baked intermediate state that hasn't
> >> > seen significant exposure t
On 11/09/2020 20:13, Han-Wen Nienhuys wrote:
I consider this fundamental flaws.
I disagree. These flaws might be a bother for developers, but
branching stable/2.22 is about not having user-visible regressions of
lilypond itself, relative to 2.20, which has nothing to do with how
developers exp
On Sep 11, 2020, at 15:19, James Lowe wrote:
>
> On 11/09/2020 20:13, Han-Wen Nienhuys wrote:
>>> I consider this fundamental flaws.
>> I disagree. These flaws might be a bother for developers, but
>> branching stable/2.22 is about not having user-visible regressions of
>> lilypond itself, relat
>> [...] if I delete a PDF file, say, `notation.pdf`, right now it
>> gets *not* rebuilt!
>
> The new documentation build has much more accurate dependency
> tracking, so if you want to rebuild notation.pdf, you can just say
> so:
>
> make out=www out-www/en/notation.pdf
Aah, I tried without `
15 matches
Mail list logo
