jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: svn commit: r644027 - /jackrabbit/tags/jackrabbit-jcr-rmi-1.4.1/
Date Thu, 03 Apr 2008 06:32:09 GMT

On undefined, Felix Meschberger <fmeschbe@gmail.com> wrote:
>  Am Mittwoch, den 02.04.2008, 23:09 +0300 schrieb Jukka Zitting:
>  > Please consider my latest JCR-1343 comment before doing the release.
>  > I'm -1 or at least -0 for an 1.4.x release that has a strict
>  > dependency on another 1.4.x component (where x>0).
>  On the one hand, I can understand you. On the other hand, going
>  componentized releases, there will be surfacing such dependencies sooner
>  or later. This cannot be prevented, in particular if the dependency
>  happens to be a support library as the commons.

I have no problem with such dependencies as such, but we should only
be making dependency changes in x.y releases, not x.y.z patch
releases. So if this had been jcr-rmi 1.5, then changing the
dependency to jcr-commons 1.5 (or even 2.0) would have been fine. IMHO
a patch release should always be a safe replacement for a previous (or
better yet, future) release from the same branch, so you never need to
worry about dependency changes if you for example replace jcr-rmi 1.4
with 1.4.1.

This is the reason why I'm so concerned about introducing new features
and improvements in patch releases.

>  Nevertheless, as we do not yet have these componentized releases, I will
>  do as you propose and copy the classes from the commons project to the
>  rmi project - only in the 1.4 branch, though, and marking the classes
>  "deprecated" with a comment.

OK, thanks! As far as I'm concerned, those copied classes could be
made package private or even private inner classes, but having them
deprecated is also fine.


Jukka Zitting

View raw message