On Tue, 2019-03-19 at 11:20 +0000, Phil Holmes wrote:
John,
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
loopback.
It would also help me
immensely if you could post a set of instructions (like the ones for
development builds in the CG at
http://lilypond.org/doc/v2.19/Documentation/contributor/minor-release-checklist).
When doing builds from stable, I confuse myself over updating VERSION
and
ensuring I push to the right branch at the right time. A set of easy
to
follow instructions would remove this barrier to updating the online
version
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.
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.
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 VERSION
gedit ly/Wel*.ly