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

[John Mandereau]

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


In step 3 on that page, always in section Pre-release, the "push"
command reads instead:

git push origin release/current


and in step 6, in any case

make LILYPOND_BRANCH=release/current lilypond


In instructions in section Actual release, use release/current instead
of release/unstable:
make lilypond-upload \
  LILYPOND_REPO_URL=git://git.sv.gnu.org/lilypond.git \
  LILYPOND_BRANCH=release/current


Instead of the commands stated in Post release, let BASE_BRANCH_STAGING
be staging if BASE_BRANCH is master, BASE_BRANCH otherwise, and do

git fetch
git checkout release/current
git merge origin/BASE_BRANCH_STAGING

gedit VERSION

git commit -m "Release: bump VERSION." VERSION
git push origin release/current:BASE_BRANCH_STAGING
git push origin :release/current


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.

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

Best,
John