jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Jackrabbit 1.5 release plan
Date Fri, 18 Apr 2008 08:43:46 GMT
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


Mime
View raw message