Am Freitag, den 11.01.2008, 17:25 +0200 schrieb Jukka Zitting: > 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.
Correct. It does not matter whether we would have done 1.4 sooner or later. The problems remain the same :-) > > 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. Well, the best solution to minimizing cross-component boundaries is to clearly define interfaces and to abide by those :-) Nevertheless, there may now and then come up such issues and we will have to cope with them. But I think the cost of these - hopefully - seldom issues is much less than the cost of cutting a release as we do now. > > > 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). Sure. What I questio is the "normal release cycle" you mention: I think we should replace it with something more suitable. > > 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. That's exactly the point I am trying to pin down: "synchronized releases". This does not work out any more, so we should not try to do it. > > 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 > ... Agreed with an important note: The jackrabbit-x.y release should NOT force release numbers onto its constituents. Just because there is a huge (or at least big) Jackrabbit x.y release, not every part of the release must be versioned as x.y. This makes migration needless complicated as it implies a requirement to an all-or-nothing migration, which is not a valid value proposition, I think. I rather see the Jackrabbit x.y releases as precanned collection of already existing releases. Its just a packaging of those, nothing new. > > > 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. Now, if we do finer releases, and the Jackrabbit x.y releases are nothing new but just repackagings, what would you branch ? Each component on release ? I would rather turn it around: If you want to work on a functionality contains big refactorings, you may branch off and work on the branch or you may use the sandbox. This second solution is how we do it over in Apache Felix. It hink this approach is much less intrusive as it places the burden solely on the developer of the big refactoring and leaves the others alone up to the point, where the refactoring is decided to be merged into the trunk. Regards Felix
