You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Some notes on how Roller releases are orchestrated.

The Release Cycle

Following the philosophy of release early and release often, Roller aims for monthly releases. New releases will generally be scheduled for once per month around the beginning of the month. This is flexible and if the team feels a given month does not warrant a new release then we will wait until the following month.

Contributing to a release

If you want to add a feature to a release, you should create a JIRA issue describing the feature, assign it to yourself, and set the "fix-for" field for the release you want. (see the roadmap view in JIRA). For all but the smallest improvements and bug fixes, you should also write a proposal and get it reviewed by the community on the development mailing list (see the [Ideas And Proposals] page). If you are working on a feature marked as IN-PROGRESS in JIRA, then when you are done you should mark it as RESOLVED. Any work that is completed should be properly documented (user guide and/or install guide), change lists should be updated, and if needed database scripts are updated and tested.

Typical release schedule

Generally the team aims to provide the first release candidate (RC1) for a new release on the second to last Thursday of each month. Beginning at that point testing begins and focuses on those features marked RESOLVED for the given release. We iterate on RCs until the community is satisfied that all tests have passed and there are no more issues which should hold up the release. Then the release goes out, ideally around the beginning of each month. At that point all items which passed testing and are included in the release are marked as CLOSED.

Release Numbers and Versions

Roller follows the typical Major.Minor.Patch version numbering convention.

Major releases

A major release is noted by a change in the major release number (i.e. 1.x to 2.x). major releases are like any other Roller release except that they are expected to include potential database schema changes and for that reason the upgrade procedure may be longer and more involved. major releases are also expected to contain larger sets of changes and more complex feature additions which were too large to complete in a minor release.

Minor releases

A minor release is noted by a change in the minor release number (i.e. 1.2 to 1.3). minor releases typically contain smaller changes to the code base and can be easily upgraded. Roller users should feel very comfortable about upgrading their Roller installation with a new minor release.

Patch releases (emergency bug fixes)

We expect that each release of roller will simply be considered a minor release, however should something unfortunate happen and we must do an emergency bug fix for a given release then we may mark that release with an incremental patch version number (i.e. 1.3.1). this is not expected to happen often.

Where Work Gets Done

This section tells you where the right place is for your code and in general how the Roller repository is structured.

Roller Trunk

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_

Roller Dev Branch

The roller dev branch will be a branch representing the next major version of roller. So if the roller trunk currently represents the 1.x code base, then the roller dev branch will be for the 2.x code. This branch is mainly created for cases where a certain feature requires enough effort that it is automatically going to be scheduled just for the next major release. This is also where all work that requires major schema changes should happen.

.h3 Custom branches
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 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/*

!!How a release happens

! Creating a new release from the trunk
coming soon.

! Creating a patch release from an old version
coming soon.

!!An Example

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

{{{
branches/roller_1.x (the old 1.x branch currently representing roller 1.3)
trunk (the current 2.x branch now representing roller 2.1 in progress)
branches/roller_3.x (the upcoming 3.x branch which doesn't have anything new yet)
}}}

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.2 (the last 1.x release) and decides it's worth taking the time to do a fix and release 1.3 from that branch.

{{{
branches/roller_1.x (now represents potential 1.4 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.x (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.x (created from trunk after last 2.2 release, represents potential 2.3 release)
trunk (now represents 3.0 release, includes Anil's tag work)
branches/roller_4.x (created for new major release work)
}}}

  • No labels