Note: This is just a proposal for now.
- Anyone can propose a release on buildr-dev, a committer must second the proposal before moving forward. Since it's easy to stop this process, using lazy consensus is good enough.
- Prioritize the issue list and drive it to zero. At this stage any issue is either blocking and must be closed, or can be safely moved to a future release. Please help identify any regression issues.
- Code freeze. Once the issue list is down to zero, give the community a calendar week (at minimum) to use it and identify any blocking issues that should delay the release. This is also a good time to update the documentation, take care of test cases, etc.
- Update the What's New page with highlights of the new release.
- Stage the release, to make sure we have a publicly accessible copy of the files that make up the release (see below for more details), and start a voting thread on buildr-dev.
- Make the release and announce it on buildr-user.
- Declare the released version as released in JIRA.
The testing should be done against the following versions of ruby. Typically we use rvm to ensure we test against each variant. So you need to ensure you have rvm installed and the following versions of ruby installed via rvm;
You must also have:
- SSH read/write access to people.apache.org and created _/public_html/buildr in your account.
- GnuPG 2.0+ private key to sign with, public key in etc/KEYS to share.
- Admin privileges for uploading release to rubyforge.org/projects/buildr.
We vote on the source distribution, but for completeness also include the binary packages (gems for now) and a copy of the updated Web site. To make sure we vote and approve the same packages that we end up distributing, stage the release before starting a voting thread.
To stage a release, run the stage task using your GPG key, for example:
$ rake stage email@example.com
The stage task runs all the necessary tests and checks. It checks that all source files contain the ASL, verifies the dependencies specified in buildr.gemspec, and runs the full test suite on both Ruby and JRuby. It also generates a copy of the Web site including the RSpec and coverage reports.
The source and binary packages are signed with your PGP key (you will need to enter your password several times), before everything is uploaded to people.apache.org//public_html/buildr/(version). ( is your home directory on people.apache.org)
When the task completes, it creates a release vote email in the file vote-email.txt. Use this to start a vote thread on buildr-dev. The vote email must point to the source distribution, binary packages, Web site, and RSpec report by their HTTP URLs.
- Start a vote thread on buildr-dev. Email subject looks like, "[VOTE] Buildr 1.3.4 release".
- Wait 72 hours.
- Tally votes and send email with vote count. Email subject looks like, "[RESULT] [VOTE] Buildr 1.3.4 release". Only PPMC member votes are binding, make sure to indicate binding votes, and separately provide total count if there are non-binding votes. (We do encourage everyone to vote early and vote often)
- Start a vote thread on firstname.lastname@example.org. This email must link to the buildr-dev vote result email and repeat the vote tally. Bonus brownie points for attaching a RAT report.
- Wait 72 hours.
- Tally votes and send email with vote count. Only IPMC member votes are binding, however, you can count votes case by IPMC members during the build-dev vote.
- Proceed to the final (and least annoying) step.
The release includes gems distributed via RubyForge; to make the release you need admin account for rubyforge.org/projects/buildr. Run the release task:
$ rake release
The release task downloads all the files that were uploaded to people.apache.org during staging. It uploads the gems to RubyForge, and uploads the new Web site, including source and binary packages and their signatures, to the Buildr web site. It takes a few hours for Apache to update the actual Web server with the newly uploaded copy of the Web site.
Once the release is publicly available, announce it on buildr-user with full details of the changes.