If the upcoming release is a new major or minor release (not a point
release, ie. bugfix release), in advance a series should be created
for it, so that milestones can be created for it, assisting with
Set the name to be the Major.Minor series version
(e.g. 2.6). Note that you can adjust this after the fact
(though it does affect some release paths), so if it's
uncertain whether a release will be a Major or Minor bump,
it's okay to create a series even if the release version is
in flux (e.g. 2.7 vs 3.0).
Fill in the Summary as best you can
Since the series is created long before the release is made and branched off, typically the Branch will be the bzr trunk: ~apparmor-dev/apparmor/master
Creating a new milestone in launchpad
Milestones in launchpad are used both for attaching releases to,
as well as for bug targeting. To create a new milestone:
Set the Name to be the Major.Minor.Micro release version (e.g. 2.6.2, 3.0.0)
Leave Code Name blank unless you're feeling creative
For Date Targeted, enter an expected release date, if known
Bump the release and library version
In a checkout out AppArmor user tools directory edit the common/Version file to have the appropriate version (eg. 2.6.0).
Note that for the 2.5.x release series only, adjusting the version means editing the VERSION variable in the common/Make.rules file.
If any changes to the libapparmor library have been made, edit the version information in libraries/libapparmor/src/Makefile.am according to the rules specified in the file.
Note that version changes will need to be coherent across all releases. This may force an update to AA_LIB_CURRENT
Commit the change and push it back to launchpad (eg. bzr commit).
You don't need to tag the commit here, we'll tag the release in bzr later on
Create the release tarball with make tarball in the top level of the checked out tree.
bzr/launchpad may have a problem with this over bzr+ssh (i.e. you're working off of the lp:apparmor or lp:apparmor/X.Y branches). If so, you can work around this by setting the REPO_URL to use the https URL, e.g. make tarball REPO_URL=https://code.launchpad.net/~apparmor-dev/apparmor/2.8
Sign the tarball with the apparmor signing key: gpg --detach-sig --armor -u firstname.lastname@example.org TARBALL
Verify that the signature was done correctly: gpg --verify TARBALL.asc
The AppArmor signing key has the fingerprint 3ECD CBA5 FB34 D254 961C C53F 6689 E64E 3D36 64BB
Perform any last minute builds and tests on the tarball to ensure there are no brown paper bag issues.
Tag the release with make tag in the toplevel of an up to date checked out tree, to ensure consistently named tags. This does the equivalent of bzr tag apparmor_VERSION (e.g. bzr tag apparmor_2.6.0).
Note that tags can be deleted and re-added if testing the generated release shows a critical bug that needs to be fixed before release.
The release note stub should have its release date updated to the current date
Move the stub from the under development section (bottom of the page) to the top of the Released version section. If this is a point release it should go under any new major release but above previous point releases. ie. the ordering is chronological by major release and then minor release.
If the next release version is known start new entry for it in the under development section at the bottom of the page and create a new page by specifying the link and after saving click on the link and edit the page for the actual release note entries.
??? Register a new series in lp - when should this be done? Before
files can be uploaded to it, but can be after branch is created
??? setting expected and release dates in lp ??? what of next release
series. ie release 2.6, should a 2.6.1 series be created at that time
as place holder for dev.
how are point releases different from major release
only tag not branch
wiki replace old point release as current version
old point release doesn't become prev version?
old version should be the most current version of
the last major release
To create a snapshot
checkout (or make sure your local copy is up to date) the appropriate bzr branch
bzr co lp:~apparmor
make the release tarball
in the base directory of the bzr tree type make tarball. This will create an appropriately named archive file. eg. apparmor-2.6.0.tar.gz
upload the release tarball to launchpad
In launchpad goto the release page pertaining to the snapshot being uploaded (from the main page click on the link to the release)
click on the Add download file link
In the Description field ????
click the Choose File button and select the tarball
GPG Signature ????
Set File content type to Code Release Tarball
click on the upload button
What of updating the release notes in lp - make sure the release
notes added have a link to the wiki release notes
Branching Userspace Trees
Some time after a new release series has been made (e.g. 2.6.0), an
official bzr branch should be made to capture fixes for future point
releases, leaving trunk available for larger scale development. This
does not need to occur immediately after the release, but should
be coordinated with the rest of the development team so that it's
understood that the only changes that should be committed to trunk
are the kinds of fixes that would be suitable for the point releases.
To do this, the following steps should be taken:
Have an up to date checkout of the trunk
tag the branchpoint on the trunk; e.g. bzr tag apparmor_2.XX_branchpoint
make a local branch of your checkout; e.g. bzr branch my_local_trunk apparmor-2.XX
change into the new branch directory; e.g. cd apparmor-2.XX
push the branch to the apparmor project on launchpad; e.g. bzr push lp:~apparmor-dev/apparmor/2.XX