checkbox-dev team mailing list archive

[Daniel Manrique <daniel.manrique@xxxxxxxxxxxxx>]

> 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.