Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of jzitting@day.com designates
 62.192.10.254 as permitted sender)
Message-ID: <6c30a2d80803171538l4e20c989y715a14ea66c03950@mail.gmail.com>
Date: Tue, 18 Mar 2008 00:38:23 +0200
From: "Jukka Zitting" <jukka.zitting@day.com>
Sender: jzitting@day.com
To: dev@jackrabbit.apache.org
Subject: Re: jackrabbit-jcr-commons release plan
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi,

On Fri, Mar 14, 2008 at 11:00 AM, Felix Meschberger <fmeschbe@gmail.com> wrote:
>  I am currently preparing the release 1.4.1 of the jackrabbit-jcr-commons
>  library.

Thanks, looks good!

I committed the JCR-1331 fix and merged it to the 1.4 branch, hoping
you'd include it in this release.

>  Issue JCR-1350 is being disputed indirectly by me proposing to add
>  JCR-1343 to the jackrabbit-jcr-rmi 1.4.1 release: If we do not add
>  JCR-1343 to the jackrabbit-jcr-rmi 1.4.1 release, JCR-1350 will not be
>  added to the jackrabbit-jcr-commons 1.4.1 release.

Looks like we're in a transitional phase with our release process, so
I'd rather be pragmatic and relax the release policies to give Sling
what it needs instead of holding things up until we come up with a
more solid component-based release process. Thus, +1 for JCR-1350 in
this release.

>  In fact considering, that we might also do more granular releases from
>  the trunk, I think JCR-1350 need not be included here for the moment.

Agreed, I'm beginning to think that we should go for a fully
component-based release process starting with 1.5. But that would
require some restructuring in trunk, so I prefer to relax the rules
temporarily for the 1.4 branch so we don't stop progress for
downstream clients like Sling before we're ready to go granular in the
trunk.

BR,

Jukka Zitting