A new release of CSF is planned for summer of 2013. This will include (at least):

  • Upgrade of Hibernate to version 3.6
  • Break-up of CSF Common Legacy into components
  • Removal of Acegi Security support (i.e. Spring Security only)

We had some discussion about how to manage this development in terms of the source code repository. There were two options:

  1. Create a branch of the CSF code to represent the current (1.0.x) release and do the release 2 development on the trunk.
  2. Create a branch of the CSF code for the release 2 development, keeping the current (1.0.x) release on the trunk.

Each approach has pluses and minuses, discussed below.

Approach 1

This approach would create a branch of the CSF code to represent the current (1.0.x) release and do the release 2 development on the trunk. This is a common way of handling new development while still being able to handle bug fixes on the current release. We would try to treat the 1.0.x release as maintenance-mode - no major new functionality, just bug fixes. Any change to this branch would need to be merged into the trunk on a regular basis - either as each change is made or on a periodic basis. Perhaps changes could be merged when they are committed to the branch, and we could also have a weekly review to verify that branch changes have been merged.

When release 2 is ready to go, we would "retire" the 1.0.x branch just by leaving it alone.

Apps currently using CSF may need to be adjusted to use the branch for their builds until they come over to release 2.

Approach 2

This approach would create a branch of the CSF code for the release 2 development, keeping the current (1.0.x) release on the trunk. Apps currently using CSF would experience no changes at all. We would try to treat the 1.0.x release (trunk) as maintenance-mode - no major new functionality, just bug fixes. Any changes to the trunk would need to be merged into the development branch, and the merges would be managed as described for approach 1 above.

When release 2 is ready to go, we would tag the trunk as the final 1.0.x version, and merge the release 2 branch into the trunk.

Apps still relying on release 1.0.x would then possibly need to change to build from the new 1.0.x branch.

Decision

The fact that the development for release 2 may be six months or so means that the final branch->trunk merge in approach 2 may be a complex and difficult task. For this reason, we decided to go with option 1.

  • No labels