Good point. I will collect all feedback and send an updated version of the proposal.
Thanks ZK 8 lut 2014 11:27 "Brendan Donegan" <[email protected]> napisał(a): > On 07/02/14 16:23, Zygmunt Krynicki wrote:> ============================= > > Checkbox Enhancement Proposal > > ============================= > > > > This proposal describes the new release process for internal Canonical > > customers of Checkbox. > > > > Advantages > > ========== > > > > * There is a tag associated with every release > > * We can eventually generate source tarballs > > * Tags from multiple components stored in lp:checkbox don't collide > > * There is a way to iterate on release candidates if important issues > are found > > * All changes made in the release branch (including tags) end up in trunk > > * The current CI system is involved to catch mistakes > > > > New Process > > =========== > > > > The new process is expressed as a series of shell commands and > assumptions. > > > > Assumptions > > ----------- > > > > * We have lp:checkbox as ~/trunk and lp:checkbox/release as ~/release > > * The process was followed before. This implies that lp:checkbox/release > has > > no patches that are not already in lp:checkbox > > * A number of new commands (not implemented) are available in the support > > directory as well as sub-commands of setup.py. Those are easy to > emulate > > manually but should be implemented to fully automate the process. > > > > 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 > > ~$ cd release > > ~/release$ ./checkbox-old/setup.py bump-version-status --to=rc1 > > This raises a question for me about how versions will work. Let's assume > the above command gives us a version '0.17.6-rc1'. Will this version only > appear when running setup.py version, or will it also appear in the version > of the debian package version (like > 0.17.5-rc1+bzr2005+201402070129~ubuntu12.04.1). > If the latter is the case then should we really be keeping this version in > two places - currently it appears in debian/changelog (in packaging) as > well. We need to have a mechanism to make sure these don't get out of sync > - either by setup.py reading from debian/changelog, or debian/changelog > getting updated from setup.py version. > > > ~/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 > > > > 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 > > > > 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 > > -- > Mailing list: https://launchpad.net/~checkbox-dev > Post to : [email protected] > Unsubscribe : https://launchpad.net/~checkbox-dev > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~checkbox-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~checkbox-dev More help : https://help.launchpad.net/ListHelp
