[Top][All Lists]

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

Re: branching stable/2.22?

From: David Kastrup
Subject: Re: branching stable/2.22?
Date: Mon, 24 Aug 2020 14:09:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jonas Hahnfeld <> writes:

> Am Montag, den 24.08.2020, 12:56 +0200 schrieb Jean Abou Samra:
>> Right, I was oblique: the scripts are fragile at present, so
>> branching release/2.22 now is no good in my opinion, but hopefully
>> we can stabilize them faster than we stabilize LilyPond as a whole,
>> and have that in 2.20.1 or 2.20.2.
>> Can you explain why porting 50 commits from master to 2.20 is a bad idea?
> I think it's a bad idea because it goes against my basic understanding
> that only bug fixes should be ported a stable branch. Here's the total
> number of commits in stable/2.20 since branching:
> $ git log --oneline release/2.20.0-1...release/2.19.65-1 | wc -l
> 588
> Sounds high at first, but most of that was translations, ie
> $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- $(ls |
> grep -vE "Documentation|po") | wc -l
> 268
> If only focusing on actual code changes:
> $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- flower/
> lily/ ly/ python/ scm/ scripts/ | wc -l
> 198
> with the majority in "core" LilyPond:
> $ git log --oneline release/2.20.0-1...release/2.19.65-1 -- lily/ ly/ scm/ | 
> wc -l
> 148

It's worth stressing that the 2.20 branch persisted much longer before
the 2.20 release than planned.  So there were also some feature
cherry-picks in order to avoid the situation that the 2.20 release would
be "outdated from the start" with regard to some "must-have" features
that would be expected to be common in suggested code on the mailing

So 2.20's history in some way reflects how to muddle through in a
situation that became a lot different from planning.  It's not really a
template for how things should work.

David Kastrup

reply via email to

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