mir/apparmor
2
0
Fork 0
mirror of https://gitlab.com/apparmor/apparmor synced 2025-08-30 13:58:22 +00:00
Code Issues Releases Wiki Activity

ReleaseProcess: initial markdown conversion

Steve Beattie 2017-11-07 13:57:01 -08:00
parent a703d727ae
commit 890d1e8479
1 changed files with 157 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

157
ReleaseProcess.md Normal file

@ -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