1
=============================
2
Checkbox Enhancement Proposal
3
=============================
5
This proposal describes the new release process for internal Canonical
11
* There is a tag associated with every release
12
* We can eventually generate source tarballs
13
* Tags from multiple components stored in lp:checkbox don't collide
14
* There is a way to iterate on release candidates if important issues are found
15
* All changes made in the release branch (including tags) end up in trunk
16
* The current CI system is involved to catch mistakes
21
The new process is expressed as a series of shell commands and assumptions.
26
* We have lp:checkbox as ~/trunk and lp:checkbox/release as ~/release
27
* The process was followed before. This implies that lp:checkbox/release has
28
no patches that are not already in lp:checkbox
29
* A number of new commands (not implemented) are available in the support
30
directory as well as sub-commands of setup.py. Those are easy to emulate
31
manually but should be implemented to fully automate the process.
36
Off-line steps, you can do them as many times as you like:
38
~$ bzr push -d trunk release
39
# TODO: pick version of packaging branck to go along with this
40
# do a test build, iterate if it fails
42
~/release$ ./checkbox-old/setup.py bump-version-status --to=rc1
43
~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
47
~/release$ bzr push lp:checkbox/release
48
~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
50
Alternatively, instead of bzr push, propose the merge to launchpad,
51
auto-approve it and have tarmac do test package builds using the packaging
52
branch reference in support/packaging-revision
54
Fixing issues found in release candidates
55
-----------------------------------------
59
~/release$ while ./tree-broken; do
61
> # Hack, cherry pick from trunk, fix locally, whatever
62
> (cd release && bzr commit)
64
~/release$ ./checkbox-old/setup.py bump-version-status --to=next-rc
65
~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
69
~/release$ bzr push lp:checkbox/release
70
~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
71
~/release$ ./support/send-email --to=... --topic "Checkboc Release Candidate Available" <<EOM
72
> The release candidate for the next checkbox release is available for
73
> testing, please check and file bugs ... and target them to milestone ...
75
> And we should improve this message one day
78
Alternatively, instead of bzr push, propose the merge to launchpad,
79
auto-approve it and have tarmac do test package builds using the packaging
80
branch reference in support/packaging-revision
82
Finalizing the release
83
----------------------
87
~/release$ ./checkbox-old/setup.py bump-version-status --to=final
88
~/release$ bzr tag $(./checkbox-old/setup.py --name)-v$(./checkbox-old/setup.py --version)
92
~/release$ bzr push lp:checkbox/release
93
~/release$ ./support/trigger-builds-in ppa:~checkbox-dev/testing
94
~/release$ ./support/ppa-copy \
95
> --from=ppa:~checkbox-dev/testing \
96
> --to=ppa:~checkbox-dev/stable \
98
~/release$ ./support/send-email --to=... --topic "Next checkbox release" <<EOM
99
> This is the next checkbox release.\
100
> It has been published to the stable PPA.
102
> And we should really improve this message one day
104
~/release$ bzr lp-propose-merge lp:checkbox -m "post-release merge back to trunk" --approve
109
If the new process is implemented correctly impact to our customers should be
110
minimal. We need to communicate the purpose of the release candidate releases
111
but apart from that the new process mirrors the effect of our current process
added
removed
cep/CEP-2.txt
