Hi,
On Jan 11, 2008 4:49 PM, Felix Meschberger <[EMAIL PROTECTED]> wrote:
> * We stop making big releases as we do now
> * We release as appropriate and as required
+1 Agreed.
I was originally thinking about making the switch to component
releases only after Jackrabbit 2.0, but it seems like we need to do at
least something along those lines already now. Our codebase is already
pretty huge and almost all parts of it are being actively developed.
Managing a release with 220 resolved issues (most of them new features
or improvements since bug fixes have already gone out in 1.3.x
releases...) has been somewhat challenging. :-)
I guess we really should have made 1.4 already earlier and had this
release be already 1.5 to lessen the amount of changes, but that
doesn't resolve the other points you raised.
The main problem I see with going with component releases is that
using Jira for release management becomes a bit tricky. So far the
"Fix version" tags in Jira have been one of my key tools in tracking
which issues go into which release. To solve that we could either
split JCR into multiple separate Jira projects, or use the component
tags to scope the release numbers. Either way we'll end up with
problems if we have an issue that affects more than one component at a
time.
One could argue that we shouldn't have cross-component issues, and
that we should first change one component in the context of one issue
and only then make related changes to another component with another
issue that depends on the first one. I don't think we are too far
ahead in componentization to make that work seamlessly, but I guess
forcing such boundaries organizationally might also help the codebase
structure.
> This results in more releases but in a much faster release turnaround.
> So for example to make an urgent release with the OCM component (just an
> example), we would not have to wait for any other component being ready
> for release. We just fix and release.
Note that there's no stopping us doing such point releases even now if
we want to, they just need to be managed outside the normal release
cycle (something like jackrabbit-ocm-1.4.0.1).
There's also an intermediate solution that I was actually planning to
propose for post-1.4. We could use the current synchronized releases
only for 1.x minor releases, and make all 1.x.y patch releases be
component-based. The bug fixes that go in patch releases are typically
much more tightly scoped and don't cross component boundaries so the
above-mentioned problems would not be that big.
With this idea the release schedule could be something like this:
jackrabbit-1.4
jackrabbit-core-1.4.1
jackrabbit-ocm-1.4.1
jackrabbit-core-1.4.2
jackrabbit-jcr-rmi-1.4.1
jackrabbit-core-1.4.3
jackrabbit-ocm-1.4.2
jackrabbit-1.5
...
> And even better: I am sure, we might even be able to prevent creating
> branches :-)
-1 With branches we can always keep the trunk free for other changes
than just bug fixes. Without a branch you always need to consider
whether it's OK to start for example some refactoring work or whether
we need to release previous bug fixes first. With maintenance branches
we can easily keep the patch releases tightly scoped to contain only
bug fixes. Backporting issues is some pain, but I think it's well
worth it.
BR,
Jukka Zitting
