~canonical-platform-qa/uci-tests/trunk

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
===============================
 Packaging HOWTO for uci-tests
===============================

Preparing
=========

 * Ensure all changes since previous release have been documented in
   NEWS.rst and that the section is for the upcoming release.

 * Set __version__ to (X, Y, Z, 'final', 0) in ucitests/__init__.py

 * Create a new debian/changelog entry and summarize the changes from NEWS.rst

   $ dch -U

 * Test that the package build correctly locally and run its tests

   $ bzr bd

 * Test that the package build and run its tests for a different series

   $ adt-run .// --setup-commands='apt-get update' --- lxc -es adt-trusty

   Note that this requires a pre-existing adt-trusty lxc container that
   should be created with:

   $ sudo adt-build-lxc ubuntu trusty

 * Note that we mostly support trusty and above for now so testing locally
   can/should be done for those series before uploading (or they will fail
   on launchpad anyway).

 * Commit and tag the release

   $ bzr commit -m 'Release X.Y.Z'
   $ bzr tag uci-tests-<X.Y.Z>

   If additional changes are required for ubuntu:

   $ debcommit


Pushing to launchpad
====================

Push the tagged branch to lp:uci-tests, check the recipes there (bzr lp-open
lp:uci-tests) or define your own if needed to create the packages for the
configured releases.


Uploading to PyPi
=================

Create the tarball in the directory above, sign it and upload it.

$ python setup.py sdist -d .. upload --sign --show-response

If the project is renamed, it needs to be registered:

$ python setup.py register


Opening next release for dev
============================

 * Set __version__ to (X, Y, Z+1, 'dev', 0) in ucitests/__init__.py

 * Create a new entry in NEWS.rst named 'dev' to hint that the version
   number for the next release is decided *when* the release is done, not
   when trunk is opened for the next release.

 * bzr commit -m 'open X.Y.Z+1 for dev'