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
Hi,

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.

BR,

Jukka Zitting

Mime
View raw message