Qpid Release Process - Background
Qpid Pre Release Steps
1. Create a wiki page and start capturing the feature/bug fix list for the release
2. We can start a discussion thread and then come to a concensus on the final list
3. These items should be tracked by jira or other means (jira is preffered)
4. We can start a parallel thread on the release dates.
Detailed Qpid Release Process
1. We should do a code freeze and put out a release candidate (ex RC1)
2. We should allow a minimum of one week for people to test/check out the RC
3. If there are major issues maybe do a RC2 and follow the same process
4. If a majority is happy then we can do a code freeze and cut out a release.
5. We should provide a 1.4 retrotranslator build of the java client (only) with each release we make
Qpid Release Process - Our Process Definition
Introduction
This document describes the general release policies used by the Apache Qpid Project to create releases of the Qpid components. As described herein, this policy is not set in stone and may be adjusted by the Release Manager. We'd like to credit the Apache HTTPD project as our heavily borrowed from template for this document - thanks !
Who can make a release?
Technically, any one can make a release of the source code due to the Apache Software License. However, only members of the Apache Qpid Project (committers) can make a release designated with Apache. Other people must call their release something other than "Apache" unless they obtain written permission from the Apache Software Foundation.
Following our official release policies, we will only accept release binaries from members of the Apache Qpid Project for inclusion on our website. This ensures that our binaries can be supported by members of the project. Other people are free to make binaries, but we will not post them on our website.
Who is in charge of a release?
The release is coordinated by the Release Manager (hereafter, abbreviated as RM). Since this job requires coordination of the development community (and access to SVN), only committers to the project can be RM. However, there is no set RM. Any committer may perform a release at any time. In order to facilitate communication, it is deemed nice to alert the community with your planned release schedule before executing the release. A release should only be made when there is a plan to publicly release it. (A release should not be made only for private distribution. A private release is more suitable for that.)
Who may make a good candidate for an RM?
Someone with lots of time to kill. Being an RM is a very important job in our community because it takes a fair amount of time to produce a stable release.
If you feel lucky, a release could be distributed without testing, but our experience has shown that this leads to a higher number of dud releases. In general, our experience has shown that a well-coordinated release fares better than non-coordinated releases. For Qpid, we are yet to establish a quality bar for releases but it's on our list of things to do !
When do I know if it is a good time to release?
In the case of Qpid, we have identified (thus far) release cutoffs when we know that a) our codebase is fairly stable, b) we have made substantial improvements or additions since any previous release and c) we have significant change coming which would preclude a release for a significant period. M2 will be our second release from Qpid so this process is evolving.
What power does the RM yield?
Regarding what makes it into a release, the RM is the unquestioned authority. No one can contest what makes it into the release. The community will judge the release's quality after it has been issued, but the community can not force the RM to include a feature that they feel uncomfortable adding. Remember that
this document is only a guideline to the community and future RMs - each RM may run a release in a different way. If you don't like what an RM is doing, start preparing for your own competing release. Note that for Qpid we do tend to take votes for such items and follow the consensus.
How does an impending release affect development?
It can not. Let's repeat that: an impending release can not affect development of the project. It is the RM's responsibility to identify what changes should make it into the release. The RM may have an intermediate tag, so the RM can merge in or reject changes as they are committed to the repository's HEAD. For Qpid, we manage our releases using svn branches.
Committers may voluntarily refrain from committing patches if they wish to ease the burden on the RM, but they are under no obligation to do so. This is one reason why we recommend that the RMs have plenty of time on their hands - they may have to deal with a rapidly changing target. It's not an easy job.
How can an RM be confident in a release?
The RM may perform sanity checks on release candidates and should always ensure that (at least) the Qpid brokers being released can be started and connected to using test clients, before distributing. All maven available test classes should be run before releasing a distribution. The release candidate should pass all of the relevant tests before making it official. Note that we are currently in the process of defining a simple set of interop tests which ensure that our client/broker combinations can talk to one another.
How to do a release?
Once the tree has been suitably tested by the RM and any other interested parties, they should "roll" the release.
Key points:
Ensure that the RM's PGP/GPG key ?? - How do we do the key bit for Qpid ??
Create an official tag based on the candidate tree
Run the tools to build the appropriate binaries/source dists - details tbc
Copy the generated release tarballs and signatures to - ?
Email qpid-dev mailing list to inform them of the release
What can I call this release?
At this point, the release is an alpha. The Qpid Project has three classifications for its releases:
Should we adopt this ??
Alpha
Beta
General Availability (GA)
Alpha indicates that the release is not meant for mainstream usage or may have serious problems that prohibits its use. When a release is initially created, it automatically becomes alpha quality.
Beta indicates that at least three committers have voted positively for beta status and there were more positive than negative votes for beta designation.
This indicates that it is expected to compile and perform basic tasks. However, there may be problems with this release that prohibit its widespread adoption.
General Availability (GA) indicates that at least three committers have voted positively for GA status and that there were more positive than negative votes for GA designation. This release is recommended for production usage.
Who can vote?
Non-committers may cast a vote for a release's quality. In fact, this is extremely encouraged as it provides much-needed feedback to the community about the release's quality. However, only binding votes casted by committers count towards the designation.
Note that no one may veto a release. Releases may not receive a designation level if a problem is found that inhibits proper functionality. The group may (implicitly or explicitly) revoke all votes on a release if there is a problem. However, if there is a -1 vote for a particular designation and there are greater than 3 positive votes and more positive than negative votes (i.e. majority consensus), the appropriate designation is conferred upon the release.
How do we make it public?
Once the release has reached the highest-available designation (as deemed by the RM), the release can be moved to the Qpid distribution directory on apache.org. Approximately 24 to 48 hours after the files have been moved, a public announcement can be made. We wait this period so that the mirrors can
receive the new release before the announcement. An email can then be sent to the announcements lists (announce@apache.org, announce@httpd.apache.org). Drafts of the announcement are usually posted on the development list before sending the announcement to let the community clarify any issues that we feel should be addressed in the announcement.
Should the announcement wait for binaries?
In short, no. The only files that are required for a public release are the source tarballs (.tar.Z, .tar.gz). Volunteers can provide the Win32 source distribution and binaries, and other esoteric binaries.
Note that the typical Win32 source distribution differs from the original tarball in that it has generated project files as well as the CRLF line endings required for that platform.
Oops. We found a problem.
At this point, the release has been created. No code changes can be made in this release. If a problem is found, it will have to be addressed in the next release or a patch can be made available. No changes can be made between alpha, beta, and GA status. The only difference is the file name that is downloaded
by the users. If an alpha tarball is created, but there was an error that can be resolved by re-rolling the tarball, it may be permissible to re-roll the release. But, the code itself may not change from designation to designation.
There are two courses of action:
Revoke the release and immediately create another one that has a fix to this problem. You can take the old release, apply the single patch, and start the voting process again. This is only recommended for critical problems found early on in the release cycle.
If the problem is less severe, place the patch to the problem in the Qpid patches directory TBC. A link to this directory should be included in the release notes with descriptions as to what problem each patch addresses.
Suggestions?
As always, if you have any suggestions or comments on our process, please feel free to email our developer mailing list (qpid-dev@incubator.apache.com) with your comments. We hope you found this document useful.
M2.1 Release process
This is what I (aidan) ran to make the Qpid release artifacts:
aidan@contemplation:~/hacking/qpid$ mkdir RC5-artifacts
aidan@contemplation:~/hacking/qpid$ svn co https://svn.apache.org/repos/asf/incubator/qpid/tags/M2.1/RC5/ qpid-M2.1-RC5
aidan@contemplation:~/hacking/qpid$ ln -s qpid-M2.1-RC5 qpid-1.0-incubating-M2.1
aidan@contemplation:~/hacking/qpid$ tar -hzcf RC5-artifacts/qpid-1.0-incubating-M2.1.tar.gz --exclude=.svn qpid-1.0-incubating-M2.1
aidan@contemplation:~/hacking/qpid$ rm qpid-1.0-incubating-M2.1
aidan@contemplation:~/hacking/qpid$ tar -zxf RC5-artifacts/qpid-1.0-incubating-M2.1.tar.gz
aidan@contemplation:~/hacking/qpid$ cd qpid-1.0-incubating-M2.1/cpp
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/cpp$ ./bootstrap && ./configure && make dist
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/cpp$ cp qpidc-M2.1.tar.gz ../../RC5-artifacts/
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/cpp$ cd ../java
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java$ mvn -Pfastinstall && cd distribution/ && mvn assembly:assembly
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java/distribution$ cp target/.gz target/.zip ../../../RC5-artifacts/
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java/distribution$ cd ../../dotnet/
aidan@contemplation:/hacking/qpid/qpid-1.0-incubating-M2.1/dotnet$ sh ./build-framing && ./release mono-2.0 aidan@contemplation:/hacking/qpid/qpid-1.0-incubating-M2.1/dotnet$ cp bin/mono-2.0/release/Qpid.NET-mono-2.0-2008414.zip ../../RC5-artifacts/
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/dotnet$ cd ../../
aidan@contemplation:~/hacking/qpid$ tar -zcf RC5-artifacts/qpid-1.0-incubating-M2.1-python-src.tar.gz qpid-1.0-incubating-M2.1/LICENSE qpid-1.0-incubating-M2.1/NOTICE qpid-1.0-incubating-M2.1/python qpid-1.0-incubating-M2.1/specs
aidan@contemplation:~/hacking/qpid$ tar -zcf RC5-artifacts/qpid-1.0-incubating-M2.1-ruby-src.tar.gz qpid-1.0-incubating-M2.1/LICENSE qpid-1.0-incubating-M2.1/NOTICE qpid-1.0-incubating-M2.1/ruby qpid-1.0-incubating-M2.1/specs
aidan@contemplation:~/hacking/qpid$ cd qpid-1.0-incubating-M2.1/java/
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java$ mvn deploy -DaltDeploymentRepository=incubator::default::file:///home/aidan/hacking/qpid/RC5-artifacts/maven -Pfastinstall
aidan@contemplation:~/hacking/qpid/qpid-1.0-incubating-M2.1/java$ cd ../../RC5-artifacts/
aidan@contemplation:~/hacking/qpid/RC5-artifacts$ rm java-src console-unix
aidan@contemplation:~/hacking/qpid/RC5-artifacts$ sha1sum *.zip *.gz > SHA1SUM
aidan@contemplation:~/hacking/qpid/RC5-artifacts$ for i in `find . | egrep 'jar$|pom$|gz$|zip$|SHA1SUM'`; do gpg --sign --armor --detach $i; done;
and then rsync it up people.apache.org
0.5 Release process
The above steps performed by Aidan have been bundled up and provided as a release script.
Located in trunk/qpid/bin the release.sh script should make the RM's job easier.
$ ./release.sh --help Usage: release.sh <svn-path> <svn-revision> <version> [options] Options: Default : --prepare -all --sign --help |-h : Show this help --prepare : Download speficied tree from svn --clean-all : Remove build artefacts and downloaded svn tree --clean : Remove built artefacts --all |-a : Generate all artefacts --source|-e : Generate the source artefact --cpp |-c : Generate the CPP artefacts --dotnet|-d : Generate the dotnet artefacts --java |-j : Generate the java artefacts --ruby |-r : Generate the ruby artefacts --python|-p : Generate the python artefacts --source|-e : Generate the source artefact --sign |-s : Sign generated artefacts --upload|-u : Upload the artifacts directory to people.apache.org as qpid-$VER
--------------------------------------------------------------------------------
Copyright © 1999-2007, The Apache Software Foundation