Hi, First off I thank you for your effort and the clean run down of how we could approach the next big one ;-)
Needless to say I am big +1 for going componentized. So here is my detailed review: Am Mittwoch, den 16.04.2008, 17:29 +0300 schrieb Jukka Zitting: > Here's my first shot at a release plan for Jackrabbit 1.5. There's > been a lot of talk about the next release and related release > processes on various forums, and I wanted to summarize a plan here to > keep everyone up to date and the momentum going towards the release. > For some background information, see also the (tentative) roadmap > presentation I gave last week during the JCR meetup in Amsterdam: > http://www.slideshare.net/day/jackrabbit-roadmap-356326 Sounds reasonable to me. > As discussed after the 1.4 release, there's still a lot we can and > should do to improve the out of the box experience with Jackrabbit. I > think this should be the primary goal for Jackrabbit 1.5, and thus I > consider the issues JCR-1455 (content explorer) and JCR-1357 (quick > start) to be the driving features of the 1.5 release. In addition to > the source code, the main release artifact should be a self-contained > runnable jar that starts up a Jackrabbit repository with WebDAV, RMI, > and browser-based content explorer features. +1 In fact the Apache Sling project already contains a simple project which bundles jackrabbit-core, WebDAV, RMI and an embedded servlet container in such a single jar file. That project can easily be extended with support of packaging this all up in a WAR file for simple deployment into a servlet container. With respect to JCR-1455 and considering the Sling project a viable solution, I think the explorer should be developped as an OSGi bundle against the OSGi HttpService specification, which may then easily be packed with the afore-mentioned Sling projects (or just about any OSGi framework providing a HttpService implementation. To make it easier of course, my personal favourite would for the explorer to actually be a Sling application ;-) Without having this discussed in the Sling community yet, I could even imagine that we might move the OSGi-bundling we did for/with Jackrabbit over to the Jackrabbit project. Such that Jackrabbit may be deployed in any OSGi framework, not just Sling. > There are a number of things going on within trunk, especially in > relation to JSR 283, but for 1.5 these new features only need to > stable enough that they don't break things if people are *not* using > them. This kind of worries me ! I would rather like to have major code changes be done in a separate branch and be merged back into trunk when done. Otherwise, we get a dependency on the state of that respective development, which is not helpfull (at best) or preventing releases (at worst). > Most notably the 1.5 release will still be based on JCR 1.0, and > more extensive changes towards JCR 2.0 should only take place after > 1.5 has been branched. As I said, major rework towards JCR 2.0 should rather be done on a separate branch and not the trunk.... > > Other fixes, improvements and new features will be included in the 1.5 > release as they become available in trunk. ++1 > Most notably I'd like to introduce the concept of the "Apache > Jackrabbit product", i.e. a self-contained repository implementation > that consists of and integrates the individual components that we > have. Now, the question is: what exactly is the "Jackrabbit product" ? Is it the core repository implementation (maybe packed in an executable jar file with embedded servlet container and explorer app) ? Or is it everything contained in the Jackrabbit project: The core implementation, the SPI, the OCM, the RMI, the WebDAV, ... > The version number of that release will be 1.5 and future > releases will follow a typical 1.5.x, 1.6, 2.0, ... pattern, but the > underlying components would be free to evolve following their own > release cycles. +1 > I'd like to push for us to have the release out during this quarter, > i.e. by the end of June. The long delay between 1.3 and 1.4 was IMHO a > mistake, and I'd like to work towards a schedule where we'd have a new > minor release roughly once per quarter. Where necessary I'd rather > postpone features than releases. This may only be possible if the features are NOT developped in the trunk. Otherwise we might start getting "branch-damaged" for regular releases to have big-trunk-rework made simpler. Not sure, whether this is good. > > The Q2 schedule for 1.5 basically means that we should have the major > new features (runnable jar deployment, content explorer) in trunk > latest in May. That's a fairly tight schedule, but I'm confident that > we can make it since the required work is mostly about integrating > existing code and solutions. > > I'd be happy if we could branch 1.5 sometime in late May, and have the > first release candidates out for testing in early June. Of course the > schedule can and probably will need to be adjusted somewhat, but I'll > try to keep everyone posted by updating this release plan. I rather would finish the componentizing and productizing discussion first before nailing down on a release dating. Because I think depending on what exactly we are going to release in June, we might end up with a different plan on branching etc... Regards Felix
