[Top][All Lists]

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

Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stabl

From: Phil Holmes
Subject: Re: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]
Date: Wed, 20 Mar 2019 12:53:10 -0000

----- Original Message ----- From: "John Mandereau" <address@hidden> To: "Phil Holmes" <address@hidden>; "Lily devel" <address@hidden>
Sent: Tuesday, March 19, 2019 10:54 PM
Subject: Can GUB-build stable/2.20 [was Re: Still cannot build GUB with stable/2.20 branch]

On Tue, 2019-03-19 at 11:20 +0000, Phil Holmes wrote:

Please let me/the list know if you're successful.

I completed a non-clean GUB build with stable/2.20 branch, in 1h07min,
done after a successful GUB build of master branch (4h05min, on a
laptop with Intel Core i7-7500U and Debian testing based system PureOS)
and a couple of commands for partial cleaning:
rm -rf uploads
rm -rf target/*/*/*lilypond*

Differently from my previous setup with Ubuntu 16.04, I don't
experience any crash on odcctools partial rebuild, but I cannot set
LILYPOND_REPO_URL with a local Git repo (i.e. with a "file:" URL)
without GUB complaining about unknown VC system, so I use SSH on

  It would also help me
immensely if you could post a set of instructions (like the ones for
development builds in the CG at
When doing builds from stable, I confuse myself over updating VERSION
ensuring I push to the right branch at the right time.  A set of easy
follow instructions would remove this barrier to updating the online
of Lily.

I'm not completely happy with the current set of instructions on page
"Minor release checklist", even for a release from master branch:
merging master into an existing release/unstable branch may import
undesired changes from the latter branch.

I understand this would be possible if someone puched a change to release/unstable without it going through staging/master. However, in the life of LilyPond I don't think it has ever happened. so may not be worth being too concerned about?

IMHO it would be better to use a _temporary_ branch for release work,
i.e. simply branch out from master (not merging anything else), then
use it for release work, then merge it into master, and finally delete
the "release" branch. This would help building a set of instructions
that works almost identically for both stable and master branches. In
either case, the general idea of the workflow is
1. branching out from main git branch, either by creating a branch
named "release/unstable" — a more generic name like "release/current"
would do — or by setting LILYPOND_REPO_URL to a local git clone;
2. doing the updates described in the CG, building, checking,
uploading, tagging;
3. merging release branch back to the main branch;
4. only in case you created a new branch in 1: deleting this branch.

An alternative would be simply to treat release/unstable as temporary? Delete it after each GUB build and recreate before. I follow Garaham's old practice of simply following the instructions on the CG to the letter, so we would need to add these steps in.

In practice, assuming BASE_BRANCH is either stable/x.y or master, and
you have fully merged previous release work to the relevant staging or
stable branch, and you don't use a local branch named "release/current"
for other purposes, replace the first set of commands on that CG page
"Minor release checklist" with

git fetch
git push origin :release/current
git checkout -B release/current origin/BASE_BRANCH
make -C $LILYPOND_BUILD_DIR po-replace
mv $LILYPOND_BUILD_DIR/po/lilypond.pot po/
gedit Documentation/web/news-new.itexi Documentation/web/news-old.itexi
gedit Documentation/web/news-headlines.itexi
gedit ly/Wel*.ly


So - to summarise - you're suggesting not building from stable/2.20 but from a new (temporary) branch, and therefore updating the new branch rather than pushing any changes to release/2.20 before a build? That sounds very sensible.

Apart my little knowledge of GUB and the release scripts, what I don't
get in all this process is at which stage the git tag is created.

Almost certain it's during lilypond-upload

Oh, and I suppose we keep using 2.19 major/minor version on stable/2.20
branch at the moment.

Yes - I think my failure to do that broke the links on the website.

Phil Holmes

reply via email to

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