Hi,
> Major new developments -- the implementation of the foreseen JCR 2.0 ACL
> functionality comes to mind -- should be done on development branches and
> merged back into trunk as the developer(s) see fit aka ready for release.
> Regular development still takes place on trunk, of course.
If done correctly, major new development can be done in the trunk
without risk. How to do that: Use a (static final boolean) constant to
enable / disable a certain new feature or new code path. It is used in
the DataStore implementation. At first, it was disabled (only enabled
when I run tests), and now it is enabled by default:
class InternalValue {
public static final boolean USE_DATA_STORE =
Boolean.valueOf(System.getProperty("org.jackrabbit.useDataStore",
"true")).booleanValue();
}
and then, everywhere where it is required, do this:
if (USE_DATA_STORE) {
// new code
} else {
// old code
}
As an added advantage, it's easy to find out if this feature is
responsible for a problem, by disabling the system property.
> * Releases are (almost) only cut from trunk
> * Branches are used for development and not for releases.
> Trunk should always be as stable as possible. Releases are built from tags
> based on trunk. This further simplifies the release procedure as there is no
> more branching and nore more bug fix back porting.
That's a good idea.
Regards,
Thomas
