jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller" <thomas.tom.muel...@gmail.com>
Subject Re: Component releases, take 2
Date Thu, 03 Apr 2008 13:51:17 GMT
Hi,

I find the current Jackrabbit downloads page a bit confusing and not
very user friendly:

    * jackrabbit-jcr-commons 1.4.2
    * jackrabbit-core 1.4.2
    * Apache Jackrabbit 1.4
    * Apache Jackrabbit 1.3.3
    * Release Archive

What exactly should a new user (that doesn't know anything about
Jackrabbit) download? Just jackrabbit-jcr-commons 1.4.2? core? What if
he doesn't speak much English? Too many options. Also, people have to
download many files and combine them later (OK, there is the .war file
that contains many jar files, but it's not documented or obvious, and
1.4.2 jars are missing). What about:

Latest Release:
Jackrabbit 1.4.2 [jackrabbit-1.4.2.zip] - Verify

Previous Release:
Jackrabbit 1.3.3 [jackrabbit-1.3.3.zip] - Verify

Other downloads:
Jackrabbit 1.4 Components
...
Jackrabbit 1.3 Components
...
Release Archive
...

The latest Jackrabbit does not need to be called 1.4.2, it could be
1.4.3 or 1.4.0.4 (that's our problem). The zip files would contain all
important .jar files and a short readme.txt. With important I mean
whatever is required to run the samples (maybe more). If possible, we
should bundle all dependencies as well. Later it could include
documentation (for example the javadocs, the JCR spec). The .war file
is not required (a link to the download page is enough).

Regards,
Thomas



On Thu, Apr 3, 2008 at 3:14 PM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
>  I've been thinking more about the proposed componentization of our
>  release process. Here's a few of my thoughts:
>
>  * There are many good reasons for breaking selected components from
>  the synchronized release model we've followed up to 1.4.
>
>  * On the other hand, component based releases
>   - increase coordination overhead for cross-component dependencies,
>   - increase release management efforts,
>   - require extra projects in the issue tracker,
>   - can be confusing to end users,
>   - prevent a simple "checkout and build" of the entire project,
>   - etc.
>
>  * Also, we should IMHO strengthen the Apache Jackrabbit brand as a
>  single product instead of a collection of components. Our JCR
>  implementation should be called "Apache Jackrabbit", not "Apache
>  Jackrabbit Core" (or some such).
>
>  * So perhaps we should adopt a subproject structure like the one in
>  many other Apache projects, where Jackrabbit is the main top level
>  product that focuses on the content repository implementation, and
>  subprojects like "JCR tools" (name ideas welcome) with their own
>  mailing lists and Jira keys could focus on things like JCR-RMI and OCM
>  that have little or no dependencies to or from the Jackrabbit content
>  repository. Such subprojects would have no trouble maintaining their
>  own independent release cycles etc. If such subprojects end up having
>  a life of their own, we could even in distant future branch them off
>  as separate TLPs.
>
>  To summarize, I believe the best approach to doing component releases
>  is by reflecting that structure also in the way the Apache Jackrabbit
>  project is organized.
>
>  BR,
>
>  Jukka Zitting
>

Mime
View raw message