Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 91784 invoked from network); 22 Jul 2008 14:48:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Jul 2008 14:48:08 -0000 Received: (qmail 42597 invoked by uid 500); 22 Jul 2008 14:48:03 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 42555 invoked by uid 500); 22 Jul 2008 14:48:03 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 42522 invoked by uid 99); 22 Jul 2008 14:48:03 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Jul 2008 07:48:03 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 22 Jul 2008 14:47:18 +0000 Received: (qmail 91427 invoked from network); 22 Jul 2008 14:47:42 -0000 Received: from localhost (HELO carsten-ziegelers-computer.local) (127.0.0.1) by localhost with SMTP; 22 Jul 2008 14:47:42 -0000 Message-ID: <4885F30D.30503@apache.org> Date: Tue, 22 Jul 2008 16:47:41 +0200 From: Carsten Ziegeler User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.14) Gecko/20080421 Lightning/0.8 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: dev@jackrabbit.apache.org Subject: Re: Component releases, proposed solution References: <510143ac0807220351m2a5fcf9bj76aafd128e5317c9@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Alexander Klimetschek wrote: > On Tue, Jul 22, 2008 at 12:51 PM, Jukka Zitting 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 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, 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 > component jackrabbit-core always gets the same version number as the > overall release - which would imply that sometimes core gets a version > number increase without an actual code change. > Ok, I guess you all will like this suggestion :) 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 release itself. Somehow would feel strange to me, that you mandate to use the same version number for core and the release but not for other essential parts. Carsten -- Carsten Ziegeler cziegeler@apache.org