incubator-celix-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1549780 - /incubator/celix/site/trunk/content/celix/documentation/releasing.mdtext
Date Tue, 10 Dec 2013 08:15:47 GMT
Author: abroekhuis
Date: Tue Dec 10 08:15:47 2013
New Revision: 1549780

CELIX-100: Updated release management page


Modified: incubator/celix/site/trunk/content/celix/documentation/releasing.mdtext
--- incubator/celix/site/trunk/content/celix/documentation/releasing.mdtext (original)
+++ incubator/celix/site/trunk/content/celix/documentation/releasing.mdtext Tue Dec 10 08:15:47
@@ -3,45 +3,55 @@ Links: documentation/releasing-links.mdt
 Note: This information is only of use to Apache Celix Release Managers!
-Loosely based on:
 Steps to follow:
-  - Be sure to have a key on file
-  - Update/Create CHANGES file
-  - Generate Release Notes (Combine with Changes?)
-  - Run complete build, including tests and coverage targets. Make sure the provided examples
-  - Run Apache RAT target
-  - Create TAG
-  - Create and sign artefacts
-  - Copy artefact and signatures to dev repo
-  - Run the Vote
-  - Tally the vote results
-  - Stage release for mirroring by copying to release repo
-  - Announce release (wait for mirror syncing) 
+  - Create signing KEYs
+  - Update release related files
+  - Compile and test
+  - Create SVN tag
+  - Create, sign and publish artefacts
+  - Run the vote
+  - Post the vote results
+  - Roll out the release artefacts
+  - Announce the release
+Interesting links:
+ - [Apache Release Guide](
+ - [Incubator Release Management Guide](
+ - [Apache Release Signing](
+ - [Apache RAT](
+ - [Apache OpenPGP Howto](
+ - [Voting Status](
+ - [Incubator Release Checklist]( (In Progress,
do we need it?)
-## Code Signing keys
+## Create signing KEYs
 Each Release Manager must have his own signing keys. Information about and instruction for
the generation of these keys can be found on the
-[Signing Releases page]( Be sure
to follow the information provided on that site and its references.
+[Signing Releases page]( and [How
To OpenPGP]( Be sure to follow the information
provided on that site and its references.
+The generated key can be uploaded to the [MIT PGP Public Key Server](
 Next, the public key signature must be added to the KEYS file. Again, read the [Signing Releases
 for more information. This updated file needs to be uploaded to SVN, be sure to upload it
-  -
-  -
+  - [Apache Celix release development area KEYS](
+  - [Apache Celix release distribution area KEYS](
-## Update Release Related Files
+## Update release related files
 For every release the related files must be updated. The following files are relevant:
      Add a list of fixed issues which can be created using Jira.
      Add additional notes regarding this release, eg known short comings.
      Even though the BUILDING file doesn't have any specific release information, it should
be verified before making a release.  
      If needed, add any new license related information to this file.
@@ -59,7 +69,7 @@ While Celix is in incubation, the qualif
 Note: The DEFAULT_VERSION property is used as default version for new bundles and as such
does not need to be updated when making a release.
-## Compile and Test
+## Compile and test
 Before creating a branch, be sure that the source compiles and tests run successfully. If
there are any known shortcomings, make sure they are listed in the 
 RELEASE_NOTES. Details for compiling and testing are available in the BUILDING file.
@@ -72,7 +82,7 @@ Apache RAT should not raise any concers,
 a license header. If it is a false positive update the rat-excludes.txt file in the root
of the project. Be sure it is a false positive! If in doubt, ask the 
 mailing list! Third party licenses may need to be mentioned in the NOTICE file.
-## Tag release
+## Create SVN tag
 After changing all files a tag for the new release must be made. Before doing so, make sure
all changed files are committed.
 The tag should be named like this: celix-X.Y.Z.incubating
@@ -83,12 +93,30 @@ svn copy
 Note: Make sure there are no new changes made on trunk while working on the release. Discuss:
Use a branch for staging the release and the files? Or possibly use a revision nr?
-## Publish Source Archive for Voting
-Copy the archive of the source to
(using SVN).
+## Create, sign and publish artefacts
+Since Celix only releases source artefacts, creating the artefact is simple and straightforward
+    // Create symbolic link so the archive has a directory with version information
+    > ln -s celix celix-X.Y.Z.incubating
+    // Create GZip archive
+    > tar -hczf celix-X.Y.Z.incubating.tar.gz celix-X.Y.Z.incubating
+    // The create symbolic link can be removed
+    > celix celix-X.Y.Z.incubating
+After creating the artefact, the file has to be signed. More information about signing can
be found at (
+    // Generate MD5 checksum
+    > md5 celix-X.Y.Z.incubating.tar.gz > celix-X.Y.Z.incubating.tar.gz.md5
+    // Generate SHA512 checksum
+    > gpg --print-md SHA512 celix-X.Y.Z.incubating.tar.gz > celix-X.Y.Z.incubating.tar.gz.sha
+    // Generate ASCII signature
+    > gpg --armor --output celix-X.Y.Z.incubating.tar.gz.asc --detach-sig celix-X.Y.Z.incubating.tar.gz
-## Run the Vote
+Copy the archive of the source to the [Apache Celix release development area](
(using SVN).
+See the [Apache Release Guide]( for more information.
+## Run the vote
 Before a release is official a vote has to be held. More information on voting can be found
on [Apache Voting Process](
 Since Apache Celix is still in incubation, both the PPMC and the IPMC have to vote for it.
@@ -101,7 +129,7 @@ Subject: [VOTE] Release Celix version X.
 This is the release vote for Apache Celix, version X.Y.Z.
 It fixes the following issues: 
-{Create Release Note link using (}
+{Create Release Note link using [Apache Celix Jira](}
 Source files:
@@ -127,7 +155,7 @@ This vote will be open for at least 72 h
 After this first vote the results must be posted to the "dev" list, see below for more information.
 The second vote has to go to the general incubator list, this is to give the IPMC a chance
to verify the release. This vote can only be published if the PPMC 
-has had enough time to review the release, following the defacto standard, this is ate least
72 hours.
+has had enough time to review the release, following the defacto standard, this is at least
72 hours.
 The template provided above can be reused for this, but needs to be extended (directly after
"This is the release vote for..." with the following information:
@@ -138,31 +166,28 @@ This release has already been approved b
   - Name of Approver (apache ID) (binding|not binding)
   - ...
-See {link to markmail archive of Celix release thread} for their votes.
+See {Create link to the archive of Celix release thread using [Markmail](}
for their votes.
-Todo: Check usability of
 Note: Be sure to use the [VOTE] tag, this is used by the automated vote tracking system to
keep track of outstanding vote threads.
-## Post Vote Results
+## Post the vote results
 As mentioned before, after each vote the results must be posted to the corresponding list.
This "Result" vote contains the number of votes made, including 
 wether a vote is binding or not.
 Note: Be sure to post the vote result as a reply to the original message. Also prepend the
subject with [RESULT]. This is, again, needed to be able to keep track
-of vote threads. See and
+of vote threads. See [Voting Status](
and [Voting Status Howto](
-## Roll Out Release
+## Roll out release artefacts
 If the vote is passed successfully the release can be moved from the "dev" area to "release".
The automated svnpubsub will move the artifact to the correct 
 server for mirroring. Mirroring typically can take up to 24 hours.
+See the [Apache Release Guide]( for more
 After these 24 hours the release can be announced. 
-## Announce release
+## Announce the release
 Update website's "news section".
-Post message to ""?
+Post message to ""?
\ No newline at end of file

View raw message