Page History

...

All tags in the subversion repository are meant to be read-only archives of versions of Roller that went final. If you are ever looking for the code to a specific version of Roller you should look here. In roller svn this is at tags/*.

An Example

Let's assume that Roller has just recently released version 2.0 and the code repository is as follows ...

branches/roller_1.0 (the old 1.x branch currently representing roller 1.3)
branches/roller_1.1 (the old 1.x branch currently representing roller 1.3)
trunk (now representing roller 2.1 in progress)

Matt has some code he has done to implement Acegi security, but he isn't sure it's going to be ready for the 2.1 release so he gets a custom branch.

branches/roller_acegi (acegi development work by Matt)

Dave and Allen finish up the 2.1 dev work and do a new release

trunk (now represents 2.2 dev work)

Somebody finds a horrible bug in 1.1 (the last 1.x release) and decides it's worth taking the time to do a fix and release 1.1.1 from that branch.

branches/roller_1.1 (now represents potential 1.1.1 release)

Matt feels comfortable that the Acegi stuff is ready, so the acegi branch is put into the current trunk so it'll go into the 2.2 release.

trunk (represents 2.2 dev work, with Matt's acegi code)
branches/roller_acegi (removed, no longer necessary)

Anil has some cool tag related feature to work on, but it requires a db change so he will work from the 3.x branch. Meanwhile, Dave, Allen, and Matt finish up the 2.2 code and do the release.

branches/roller_3.0 (anil doing tag work)
trunk (now represents 2.3 dev work)

Anil says his tag stuff will be ready within the month and the team agrees that now is a good time for a major release.

branches/roller_2.2 (created from trunk after last 2.2 release, represents potential 2.2.1 release)
trunk (now represents 3.0 release, includes Anil's tag work)
branches/roller_4.0 (created for new major release work)

Step-by-step How to Create a Release

...

If you haven't already, you will also need to upload your public key to Roller's KEYS file in SVN, as well as the KEYS file in the Roller distribution folder (they are not presently the same.)  This has to be done only once for Roller no matter how many releases you make.  First use "gpg --list-keys" to determine the 8 character key ID for your key, and then make an ASCII armored key for it and add it to the MIT public key server.  For the SVN KEYS file, as it is in a top-level directory that would result in downloading tons of files if you tried a full checkout, do an empty checkout of the folder (to avoid downloading the several large artifacts in this folder's hierarchy) and then an individual file svn update to get just the KEYS file, add your public key to it using the instructions at the top of the file, and then commit the KEYS file back:

svn co https://svndist.apache.org/repos/dist/asfrelease/roller --depth=empty
cd roller
svn update KEYS
(add public key to KEYS)
svn commit KEYS -m "Added my key to KEYS file."

...

svn copy https://svn.apache.org/repos/asf/roller/branches/roller_5.0  https://svn.apache.org/repos/asf/roller/tags/roller_5.0.4-rc1

5. Move artifacts to Roller Dist - Dev folder and Vote on release

We use svnpubsub for our distribution releases (docs).  We upload the artifacts to the dist/dev/roller folder (using svn add) when we hold the vote.  After the vote is approved use an svn move to move the artifacts to the dist/release/roller folder.  As the dist/dev and dist/release folders have countless artifacts from all the other Apache projects, use the SVN --depth=empty commands below to check out just the Roller folders, as shown in the following SVN commands:

svn co https://dist.apache.org/repos/dist roller-dist --depth=empty
cd roller-dist
svn update dev --depth=empty
svn update dev/roller
svn update release --depth=empty
svn update release/roller

Use svn add & svn commit to place the artifacts in the dev/roller/roller-5/v5.?/src, /docs, and /bin folders, similar to that done for earlier releases.

Call for a release vote on the DEV list and once the release is approved, move to the next step.  If there are any not-yet-publicized security issues that the patch fixes, don't mention them in that public email but do so instead on the separate Roller private (PMC-only) list. 

6. Move release files into place

Login to people.apache.org and move the release files into the directory tree in the right place. For example, for a Roller 5.0.4 release files would go under the roller-5 directory.

Do an svn (remote) move of the dist/dev/roller/roller-5/v?.?.? folder to the dist/release/roller/roller-5 directory.  With this change the dev directory should be empty.  From the release/roller folder, do an svn rm of older releases from the same branch and of older, no-longer-supported branches as a result of the new release.  (Older releases are already archived elsewhere by the infrastructure team.) Wait up to 24 hours for mirrors to update.

As these files are huge it is considerably faster to move the files remotely on the SVN server instead of doing a local svn move followed by an SVN commit of those files back to the server, for example:

dist$ mkdir release/roller/roller-5/v5.0.4
dist$ svn commit release/

   /www/www.apache.org/dist/roller/roller-5/v5.0.4 -m "Folder for new 5.0.4/src release"
dist$ svn move https:/www/wwwdist.apache.org/repos/dist/dev/roller/roller-5/v5.0.4/docs
   /www/www https://dist.apache.org/repos/dist/release/roller/roller-5/v5.0.4/bin

Wait 24 hours for mirrors to update. Once that happens you should delete the old release files for previous versions of Roller. They are already archived elsewhere by the infrastructure team.

7. Update the website to point to the new files

Update the website files 's download and sidebar links in SVN and update to publish them.

8. Announce the release, update branch version

...