Hi, On undefined, Felix Meschberger <[EMAIL PROTECTED]> 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
