On Fri, Oct 16, 2020 at 1:02 PM Michael Käppler wrote:
> Hi all,
> a few days ago I wanted to try how some functionality in LilyPond
> worked, when it was added long
> time ago. (about 15 years ago, around 2.7.x or 2.8.x)
> Not very surprisingly I could not even get the code to compile with my
>
On Fri, Oct 16, 2020 at 11:41 AM Jonas Hahnfeld wrote:
>
> So master is 2.23.0 and usual development can resume, with the pleading
> to avoid disruptive changes that make picking harder than necessary.
> Fixes should also go to master and I'll pick them to the branch. If you
> really need to do t
Hi all,
a few days ago I wanted to try how some functionality in LilyPond
worked, when it was added long
time ago. (about 15 years ago, around 2.7.x or 2.8.x)
Not very surprisingly I could not even get the code to compile with my
current build setup.
That made we wonder if it would be a good idea
Am 16.10.2020 um 15:52 schrieb Jonas Hahnfeld:
Am Freitag, den 16.10.2020, 15:46 +0200 schrieb Michael Käppler:
Am 15.10.2020 um 23:03 schrieb Werner LEMBERG:
we're using both `@url` and `@uref` commands in our documentation,
the overwhelming majority is `@uref`.
michael] ~/lilypond/Documentat
Am Freitag, den 16.10.2020, 20:01 +0200 schrieb Jean-Charles
Malahieude:
> Le 16/10/2020 à 19:41, Jonas Hahnfeld a écrit :
> > Hi all,
> >
> > I created stable/2.22 as discussed and the situation is as follows:
> > * b7c2bc5feb (origin/master) Reset Changes document for next cycle
> > * 7f0bb931c3
Le 16/10/2020 à 19:41, Jonas Hahnfeld a écrit :
Hi all,
I created stable/2.22 as discussed and the situation is as follows:
* b7c2bc5feb (origin/master) Reset Changes document for next cycle
* 7f0bb931c3 Bump VERSION to 2.23.0 for next cycle
| * 8a58e932f8 (origin/stable/2.22) ci: Build branch o
Hi all,
I created stable/2.22 as discussed and the situation is as follows:
* b7c2bc5feb (origin/master) Reset Changes document for next cycle
* 7f0bb931c3 Bump VERSION to 2.23.0 for next cycle
| * 8a58e932f8 (origin/stable/2.22) ci: Build branch on push
| * b63a51f52f (origin/translation) Bump VE
Folks,
can someone please explain to me why the following code
{
\compressEmptyMeasures
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 | \break
R4*120 | \break
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4 4 4 | 4 4 4 4 | 4 4
Am Freitag, den 16.10.2020, 15:46 +0200 schrieb Michael Käppler:
> Am 15.10.2020 um 23:03 schrieb Werner LEMBERG:
> > > we're using both `@url` and `@uref` commands in our documentation,
> > > the overwhelming majority is `@uref`.
> > >
> > > michael] ~/lilypond/Documentation/en (master)]> git gre
Am 15.10.2020 um 23:03 schrieb Werner LEMBERG:
we're using both `@url` and `@uref` commands in our documentation,
the overwhelming majority is `@uref`.
michael] ~/lilypond/Documentation/en (master)]> git grep '@url' | wc
-l
9
michael] ~/lilypond/Documentation/en (master)]> git grep '@uref' | wc
[lilypond git 647e127c07a794d087c5e39bf23c0d4a7d66a957 from Oct. 6th]
Folks,
can someone please explain to me why the following code
{
\compressEmptyMeasures
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 | \break
R4*120 | \break
c'4 4 4 4 | 4 4 4 4 | 4 4 4 4 | 4 4 4 4 |
c'4 4
On Fri, Oct 16, 2020 at 3:32 AM Carl Sorensen wrote:
> Unfortunately, I’m not capable of handling this problem right now.
>
>
>
> But it’s hard for me to imagine that something that would require a major
> version bump is only a week’s worth of work. I’ve copied Han-Wen to try to
> understand mo
Am Freitag, den 16.10.2020, 08:17 +0200 schrieb Michael Käppler:
> Am 16.10.2020 um 01:41 schrieb Dan Eble:
> > On Oct 15, 2020, at 09:26, Jonas Hahnfeld wrote:
> > > Am Dienstag, den 13.10.2020, 15:11 +0200 schrieb Jonas Hahnfeld:
> > > > After creating the branch, I will (unless somebody doesn't
13 matches
Mail list logo
