THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
When a Roller PMC member would like to make a release at some point in the future, he/she simply proposes that release to the Roller private dev mailing list.
After some of the planned features are added, a committer may propose a milestone build. Milestone builds are not official releases, each is just a snapshot, so formal vote is not required, only lazy consensus. They may be tagged in SVN Git and are made available via informal mechanisms, e.g. a committers peoplehttps://dist.apache.org space/repos/dist/dev/roller. They are meant for testing only and not intended for production use, so there will be no migration scripts to help folks migrate data from milestone M1 to M2, etc.
Once a committer feels that the release is completely ready, he/she proposes to start making release candidates, also made available via https://dist.apache.org/repos/dist/dev/roller. A release candidate is a complete release, signed and ready to be shipped. Like milestone releases, release candidates are not official releases. They are meant for testing only and not intended for production use. After some feedback and testing has occurred and a release candidate appears to be good for final release, a vote is called. Once there are three +1 votes from PMC members the release can be made.
...
This section tells you where the right place is for your code and in general how the Roller repository is structured.
Roller
...
Master
The Roller trunk is the main development repository and will try to always represent the version of the code base currently being developed for the next release. Each new release will be made from the trunk and distributed as appropriate. It is expected that any code commited to the trunk will be in full working order _in time for the next scheduled release_
...
A custom branch can be created whenever a feature is in development that is not on a certain schedule. this allows the custom branch to worked at whatever pace is desired and when the code is ready it can be applied to whatever branch is most appropriate.
Tags
All tags in the subversion Git 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 Git 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 ...
| Code Block |
|---|
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.
| Code Block |
|---|
branches/roller_acegi (acegi development work by Matt)
|
Dave and Allen finish up the 2.1 dev work and do a new release
| Code Block |
|---|
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.
| Code Block |
|---|
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.
| Code Block |
|---|
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.
| Code Block |
|---|
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.
| Code Block |
|---|
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
NOTE: these instructions are for the Roller 5.0 branch and with Roller 5.1 (yet to be released) these instructions will change.
1. Obtain and update the source code.
Check out the Apache Roller source code from the appropriate branch. Within the pom files, update the Roller version number to what you will be releasing (for example, 5.0.4-SNAPSHOT to 5.0.4). Update the version within the three sign*.sh files to that version as well.
2. Create release for Tomcat
The commands below will create the Roller for Tomcat release bundle in ZIP and Gzipped TAR formats and the ASCii signature files:
| Code Block |
|---|
./build-tomcat-release.sh
./sign-tomcat-release.sh
|
Once done, move the four files (tar/gz & .asc for them) outside of weblogger-assembly/target folder (otherwise, those files will be lost in the Java EE build in the next step).
3. Create release for Java EE
The commands below will create the Roller for Java EE release bundle in ZIP and Gzipped TAR formats and the ASCii signature files:
| Code Block |
|---|
./build-javaee-release.sh
./sign-javaee-release.sh
|
After that, files will be in the roller/dist directory.
4. Upload files for review
Upload to your home directory the files on people.apache.org, for example for RC1 you might put them here:
| Code Block |
|---|
/home/<username>/public_html/rc1
|
5. Check In Version changes
Do an SVN commit of the changes you did in Step #1. Then, add a release candidate tag using the svn copy command, for example:
| Code Block |
|---|
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. Vote on release
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.
| Code Block |
|---|
/www/www.apache.org/dist/roller/roller-5/v5.0.4/src
/www/www.apache.org/dist/roller/roller-5/v5.0.4/docs
/www/www.apache.org/dist/roller/roller-5/v5.0.4/bin
|
...
Step-by-step How to Create a Release
1. Create a stable branch for the release
Name the branch with the format roller-{version}, e.g. roller-5.2.0
2. Update version numbers
You will need to change the version numbers in at least the files below:
pom.xml app/pom.xml assembly-release/pom.xml assembly-release/sign-release.sh it-selenium/pom.xml it-selenium/src/test/resources/roller-jettyrun.properties docs/roller-install-guide.odt docs/roller-user-guide.odt docs/roller-install-guide.odt3. Build Roller
Run a full build & test with "mvn install". If tests fail, you need to figure out why and rectify.
$ mvn install4. Build the release package
Change directory into the assembly-release directory and do a Maven build there: "mvn package"
$ cd assembly-release $ mvn package5. Sign the release
Before you can do this, you need to have GPG setup and a key in place for signing releases. To sign the release, you can use the sign-release.sh script in the assemly-release directory like so:
$ ./sign-release.sh6. Make the release available
You make the release available by committing it to a Subversion (SVN) repo at https://dist.apache.org/repos/dist/. Get that repo and take a look at the directory structure there. If you are creating a Release Candidate (RC) then it will go into a subdirectory of the "dev" directory and if you are making a final release, then it must go into the "release" directory.
For example a 5.2.0 RC1 release would go into
./dev/roller/roller-5.2/v5.2.0-rc-1Another example, a final 5.2.0 release would go into
./release/roller-5.2/v5.2.07. Update the website to point to the new files
Update the website files in SVN and update to publish.
8. Announce the release, update branch version
Make the announcement on the mailing list and other places, and update the branch to the next snapshot version (e.g., 5.0.4 to 5.0.5-SNAPSHOT)'s download links to point to the new release.