From 890d1e8479cfe29ee7d331f635cee8fe652d5c34 Mon Sep 17 00:00:00 2001 From: Steve Beattie Date: Tue, 7 Nov 2017 13:57:01 -0800 Subject: [PATCH] ReleaseProcess: initial markdown conversion --- ReleaseProcess.md | 157 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 157 insertions(+) create mode 100644 ReleaseProcess.md diff --git a/ReleaseProcess.md b/ReleaseProcess.md new file mode 100644 index 0000000..e0e6081 --- /dev/null +++ b/ReleaseProcess.md @@ -0,0 +1,157 @@ +AppArmor Release Process Notes +============================== + +This page is an attempt to capture the AppArmor release process. + +Making a Userspace Release +-------------------------- + +### Release Preparation + +During the run-up to a release, it's helpful to do some preparation +work. + +1. Review trunk check-ins and decide which should be included +2. Write release notes, summarizing the changes as in [ReleaseNotes\_2\_8](ReleaseNotes_2_8): + - New features + - Language changes + - Improvements + - Bug fixes + - Profile changes + +#### Creating a new series in launchpad + +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 +bug targeting. + +1. https://launchpad.net/apparmor/+addseries + - 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: +1. https://launchpad.net/apparmor/X.X/+addmilestone where X.X is the + series the milestone is being created for (e.g. 2.6 for a 2.6.1 + release 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 + +### Official Releases + +1. 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. + 1. 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). + 1. You don't need to tag the commit here, we'll tag the release in bzr later on +2. 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` +3. Sign the tarball with the apparmor signing key: `gpg --detach-sig --armor -u apparmor@lists.ubuntu.com TARBALL` +4. 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** +5. Perform any last minute builds and tests on the tarball to ensure there are no brown paper bag issues. +6. 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. +7. \[Optional\] upload packages based on the release to the appropriate apparmor-dev ppa: https://launchpad.net/~apparmor-dev/+archive/apparmor-X.Y (where X.Y is the series version) +8. Create a new release from the milestone: https://launchpad.net/apparmor/+milestone/X.Y.Z/+addrelease + - Once a release has been created in launchpad, files can be uploaded to it +9. Upload the tarball and detached gpg signature to the launchpad page: https://launchpad.net/apparmor/X.Y/X.Y.Z/+adddownloadfile (where X.Y is the series and X.Y.Z is the specific version) + - The **Description** field should just be **AppArmor X.Y.Z** +10. [Branch the release](ReleaseProcess#Branching_Userspace_Trees) (For major releases only) + - For point releases (2.6.x) a new branch is unnecessary, as only stable patches are being applied. The tag is sufficient to identify the release points. +11. Update wiki + - Update the release notes. There are two separate entries for release notes: + 1. A stub entry on the [release notes](AppArmor_versions) page. + - 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. + 2. the full release notes for the release on their own page [ReleaseNotes\_X\_X\_X](ReleaseNotes_X_X_X) (e.g. [ReleaseNotes\_2\_6\_0](ReleaseNotes_2_6_0)): + - Previous release notes can be used as a template. + - Update current release information on the [main page](Main_Page#Userspace) + - if major release or point release for the most recent major release, update **Current stable release** + - if point release for an older release series, update **Prior supported release** +12. Mirror to kernel.org (require kernel.org account) + - Mirror release tarball + - If major release create a release directory in **/pub/linux/security/apparmor/**. + - minor releases use the major release directory, but have the point release as part of their name + - copy release tarball into the release directory, it should contain the release name. eg. apparmor-2.6.1.tar.gz + - copy in the md5 checksum into release directory into a file named after the release. eg. apparmor-2.6.1.md5 + - Make sure git mirror of apparmor bzr tree is up to date + - update kernel.org git mirror of bzr ???? + - **/pub/scm/linux/security/apparmor/** + - Make sure any additional kernel patches are synced to the apparmor kernel tree + - **/pub/scm/linux/kernel/git/jj/apparmor-dev.git/** +13. Send announcement of the release to the apparmor mailing list **apparmor@lists.ubuntu.com** +14. Make a copy of the announcement on the launchpad page at https://launchpad.net/apparmor/+announce +15. Go through bugs targeted to the milestone https://bugs.launchpad.net/apparmor/+milestone/X.Y.Z and either close them or move them to a different milestone if they were not fixed by this release + +> ??? 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 + +### Snapshots + +To create a snapshot + +1. checkout (or make sure your local copy is up to date) the appropriate bzr branch + - `bzr co lp:~apparmor` +2. 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 +3. 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: + +1. Have an up to date checkout of the trunk +2. tag the branchpoint on the trunk; e.g. `bzr tag apparmor_2.XX_branchpoint` +3. make a local branch of your checkout; e.g. `bzr branch my_local_trunk apparmor-2.XX` +4. change into the new branch directory; e.g. `cd apparmor-2.XX` +5. push the branch to the apparmor project on launchpad; e.g. `bzr push lp:~apparmor-dev/apparmor/2.XX` +6. Associate the branch with the release series: https://launchpad.net/apparmor/X.X/+setbranch (replace X.X with the release version, e.g. 2.6) +7. I usually blow away the pushed branch locally and re-checkout the new branch to verify that the aliases are working right; e.g. `bzr co lp:apparmor/2.XX` +8. Modify the bzr REPOURL location in the top level Makefile to match the new branch; make tarball needs this to be correct for subsequent releases off of the branch, +9. edit common/Version to adjust in preparation for the XX+1 release with something like 2.XX.90 (git doesn't like '~' in tags, so versioning like 2.XY~pre1 are a bad idea) +10. send email to list **\[administrative\] AppArmor 2.XX branch created**, with branch url and note about needing nominations