> Cutting the release > ------------------- > > Off-line steps, you can do them as many times as you like: > > ~$ bzr push -d trunk release > # TODO: pick version of packaging branck to go along with this > # do a test build, iterate if it fails
We need a standard way to do the test builds. It can be a separate proposal, it's orthogonal to this but they do intersect at some point. > ~$ cd release > ~/release$ ./checkbox-old/setup.py bump-version-status --to=rc1 > ~/release$ bzr tag $(./checkbox-old/setup.py > --name)-v$(./checkbox-old/setup.py --version) can setup.py also do this second step? can we have a tool that does that? (it'll eventually fall off my bash history and I'll spend minutes chasing documentation when it should take seconds). > > On-line steps: > > ~/release$ bzr push lp:checkbox/release > ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing > > Alternatively, instead of bzr push, propose the merge to launchpad, > auto-approve it and have tarmac do test package builds using the packaging > branch reference in support/packaging-revision We'd have to add a tarmac-build script for this, and amend the tarmac configs, right? > > Fixing issues found in release candidates > ----------------------------------------- > > Off-line steps:: > > ~/release$ while ./tree-broken; do > > (cd bzr && vim .) > > # Hack, cherry pick from trunk, fix locally, whatever > > (cd release && bzr commit) > > done > ~/release$ ./checkbox-old/setup.py bump-version-status --to=next-rc > ~/release$ bzr tag $(./checkbox-old/setup.py > --name)-v$(./checkbox-old/setup.py --version) > > On-line steps:: > > ~/release$ bzr push lp:checkbox/release > ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing > ~/release$ ./support/send-email --to=... --topic "Checkboc Release > Candidate Available" <<EOM > > The release candidate for the next checkbox release is available for > > testing, please check and file bugs ... and target them to milestone ... > > > > And we should improve this message one day > > EOM > > Alternatively, instead of bzr push, propose the merge to launchpad, > auto-approve it and have tarmac do test package builds using the packaging > branch reference in support/packaging-revision > > Finalizing the release > ---------------------- > > Off-line steps:: > > ~/release$ ./checkbox-old/setup.py bump-version-status --to=final > ~/release$ bzr tag $(./checkbox-old/setup.py > --name)-v$(./checkbox-old/setup.py --version) > > On-line steps:: > > ~/release$ bzr push lp:checkbox/release > ~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing > ~/release$ ./support/ppa-copy \ > > --from=ppa:~checkbox-dev/testing \ > > --to=ppa:~checkbox-dev/stable \ > > --packages=... > ~/release$ ./support/send-email --to=... --topic "Next checkbox release" > <<EOM > > This is the next checkbox release.\ > > It has been published to the stable PPA. > > > > And we should really improve this message one day > > EOM > ~/release$ bzr lp-propose-merge lp:checkbox -m "post-release merge back > to trunk" --approve > > Impact > ====== > > If the new process is implemented correctly impact to our customers should be > minimal. We need to communicate the purpose of the release candidate releases > but apart from that the new process mirrors the effect of our current process This is OK. In practice we haven't had that many fixes resulting from testing a pre-release, but this makes that part of the process a bit more formal. -- Mailing list: https://launchpad.net/~checkbox-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~checkbox-dev More help : https://help.launchpad.net/ListHelp
