Re: Component releases, proposed solution

Hi, Thomas Müller schrieb: Hi, Major new developments -- the implementation of the foreseen JCR 2.0 ACL functionality comes to mind -- should be done on development branches and merged back into trunk as the developer(s) see fit aka ready for release. Regular development still takes place on

Re: Component releases, proposed solution

Hi, On Wed, Jul 23, 2008 at 9:35 AM, Felix Meschberger [EMAIL PROTECTED] wrote: As corrolary to these notes, I would add (yes these will be controversial, I know): * Branches are used for development and not for releases. * Releases are (almost) only cut from trunk * In case of an

Re: Component releases, proposed solution

Hi, If done correctly, major new development can be done in the trunk without risk. Sure, if it only concerns a single location or limited set of locations. If it touches multiple places, this is not that easy. USE_DATA_STORE is used in multiple places, I don't think it's a big problem. And

Re: Component releases, proposed solution

Hi Jukka, Thanks for bringing this up in this concise form. I basically agree with what you propose. Yet a big question turns around in my head: What exactly _is_ Jackrabbit ? Well, Jackrabbit is a JCR 1.0 implementation you might say. Quite true. But this falls short, because this only

Component releases, proposed solution

Hi, There's been a lot of discussion about release strategy and componentization lately, and I've been trying to figure out how to fit all the different requirements into a single solution for Jackrabbit 1.5+. Here's what I have in mind... First, the main requirements for componentization: *

Re: Component releases, proposed solution

On Tue, Jul 22, 2008 at 12:51 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Applied to the Jackrabbit 1.4.x release cycle, this would have given us the following releases: * Jackrabbit 1.4.1, including core 1.4.1 * Jackrabbit 1.4.2, including core 1.4.2 * Jackrabbit 1.4.3, including jcr-commons

Re: Component releases, proposed solution

Hi, I'm not sure about all the implications such a change has, but I like the idea to have an overall jackrabbit release version. It would certainly make downloading and using the latest jackrabbit version a lot easier. regards marcel Jukka Zitting wrote: Hi, There's been a lot of

Re: Component releases, proposed solution

Hi, On Tue, Jul 22, 2008 at 3:30 PM, Alexander Klimetschek [EMAIL PROTECTED] wrote: Generally I agree, but I know that something like jackrabbit 1.4.6 containing a 1.4.5 core jar would be very confusing when users report a problem. Couldn't we make an exception that the most important

Re: Component releases, proposed solution

Hi, We went down this path in a rather large project and it didn't end up working out. The follow up on the mailing lists from people who weren't using a dependency manager and were continually confused by version numbers was a real pain. In the end we went back to a single version number

Re: Component releases, proposed solution

* Jackrabbit 1.4.1, including core 1.4.1 * Jackrabbit 1.4.2, including core 1.4.2 * Jackrabbit 1.4.3, including jcr-commons 1.4.1 and jcr-rmi 1.4.1 * Jackrabbit 1.4.4, including core 1.4.3 * Jackrabbit 1.4.5, including core 1.4.4 * Jackrabbit 1.4.6, including core 1.4.5 Generally I agree,

Re: Component releases, proposed solution

Alexander Klimetschek wrote: On Tue, Jul 22, 2008 at 12:51 PM, Jukka Zitting [EMAIL PROTECTED] wrote: Applied to the Jackrabbit 1.4.x release cycle, this would have given us the following releases: * Jackrabbit 1.4.1, including core 1.4.1 * Jackrabbit 1.4.2, including core 1.4.2 * Jackrabbit

Re: Component releases, proposed solution

Hi, On Tue, Jul 22, 2008 at 5:47 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: What about using a completly different versioning for the release, like jackrabbit 2008-07 or 1.4.200807 :) Or something completly different which keeps you free of using the same version numbers for core and the

Re: Component releases, proposed solution

Hi, Alternatively, how about if the modified component always got the top level version number? That way we'd have gaps in the component version numbers, but it would always be easy to correlate the component version number with the top-level release that first contained it. +1 for the 'gap

Re: Component releases, proposed solution

Jukka Zitting wrote: Hi, On Tue, Jul 22, 2008 at 5:47 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: What about using a completly different versioning for the release, like jackrabbit 2008-07 or 1.4.200807 :) Or something completly different which keeps you free of using the same version

Re: Component releases, proposed solution

Hi, On Tue, Jul 22, 2008 at 7:37 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Hmm, but wouldn't this mean that let's say Jackrabbit 1.4.4 include jcr-commons 1.4.3 given that commons hasn't changed in the meantime? Correct. But that probably wouldn't be too troublesome, as if the user can