Hi Roland, Am Samstag, den 19.01.2008, 21:23 +0100 schrieb Roland Weber: > Hi Felix, > > >>> > > * jackrabbit-classloader: There isn't much work going on here, apart > >>> > > from bugfixing. So there will be no reasons for new releases ! > >> > > >> > Even bug fixes need to be released. Are you suggesting we just drop > >> > the component? > > > > Definitely not, there will be bugfixes and we will not drop this. But we > > should certainly not raise the version number and create new releases > > just for fun. I would say the classloader component is largely in > > maintenance mode at the moment. > > [...] > > Again: No changes, no release, no management. Therefore we should strive > > for this separation. > > I don't quite understand how you would want to handle these "no release" > components.
By "no release" I mean, that there no "mvn release" call is done with the consequence of raising the version number, tagging etc. Of course we still distribute these components. > Just depend on the released 1.4 version and delete the code > from trunk? Or move them to a separate component in the trunk already? Of course, each component in Jackrabbit should always depend on a released version of any other component, be it external or internal to Jackrabbit, with the exception of dependencies on functionality added after the release. For example: Consider jackrabbit-core and jackrabbit-api: As long as there is no change in jackrabbit-api, jackrabbit-core 1.5-SNAPSHOT still depends on jackrabbit-api 1.4. After an addition to jackrabbit-api, which is used by jackrabbit-core, the latter will be modified to depend on jackrabbit-api 1.5-SNAPSHOT. But of course, everything we are still working on remains in trunk. > The latter requires a new component build process, hence effort. Definitely is this required ! Currently it looks like Jukka is just doing a "mvn release" on the jackrabbit branch root, thus incrementing versions, tagging and packaging each component (aka module) refereced in the root pom.xml. What I envision is, that the "mvn release" is called on each module separately as appropriate and required. This also requires that we split the root pom.xml into two (as is also done in Apache Felix and Apache Sling and works quite well): One aggregator pom.xml at the root, which just contains the module references and a separate real parent pom.xml in its own subfolder. > Where > should issues be reported? To the JIRA for the "main" cluster, where there > is still a JIRA component for the spun-off code? Or create the new JIRA > project right away? That would imply effort again, at least at Infra. > And if you don't do the preparations right away, you'll face a steep hill > to climb if there is need for a new release. Not sure, whether this is really required right away. I think, the problem with JIRA is somewhat overstated. I don't think, that it is this problematic. We may well keep the current single-project setup but we will have to more intensly manage the version numbers. > > A reasonable approach seems to be to start with the undisputed components > (JCRAPI, JCRSPI, JCRRMI) and learn by doing how much effort it is. > Additional projects can always be spun off from the "main" cluster later. +1 Regards Felix
