Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=R2v1nbJ8MOx05FvsAaT8UVw9243Kt5gcfgQuHGixYmfIuAf9d8F5zDxKJxCy99nP+Ke/tTTonMr9V57lgl33dx2NT55BgzqiqahomA5hpOp20pMcnDqkXJoijFmuoUlCicdTSUbx31NZL5fhNNC8LB2gujYv5j+nwQrTWoY4X8s=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <00E083D3-4F56-4311-945B-B5F35773F3A0@iq80.com>
References: <77D3BF90-B687-4DD8-A7EF-260828356870@planet57.com>
 <8DF9A0D8-2D78-4D01-A6BD-ACA30F0E11F4@yahoo.com>
 <85A23AE0-3774-4E6E-BF5F-F874729627E4@visi.com>
 <00E083D3-4F56-4311-945B-B5F35773F3A0@iq80.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3D4F4025-0106-4546-9E45-1DEE3E936E90@planet57.com>
Content-Transfer-Encoding: 7bit
From: Jason Dillon <jason@planet57.com>
Subject: Re: One version for specs
Date: Mon, 2 Oct 2006 12:22:20 -0700
To: dev@geronimo.apache.org
Sender: Jason Dillon <jason.dillon@gmail.com>

I don't think that 1.5 development will result in new releases...  
those will all be SNAPSHOT artifacts anyways.

Just some questions about this strategy...

Which modules go where?  Will each of these trees have a single  
version?  How will the overlap between J2EE 1.5 and 1.4 fit?  Where  
will common config go?

--jason


On Oct 2, 2006, at 11:55 AM, Dain Sundstrom wrote:

> How about we split them into j2ee 1.4, j2ee 1.5 and independent  
> modules for the non j2ee specs?  This will prevent the flux from  
> the 1.5 development from causing lots of new versions for the 1.4  
> specs.
>
> Just another middle ground idea.  Thoughts?
>
> -dain
>
> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>
>>
>> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>>
>>> In any case PLEASE think about this and make your opinion known  
>>> soon.
>>
>> If we could at least make a compromise that'd be very great, all  
>> or nothing is not the only way.
>>
>> Maybe we could just remove these core specs from trunk or  
>> something (we have several tags):
>>
>>  ejb
>>  servlet
>>  jsp
>>  jms
>>  transaction
>>  connector
>>  qname
>>
>> If all the rest became "one version number" specs released at the  
>> pace of the most changing spec, that'd still be less desirable but  
>> be at least better.
>>
>> Maybe not the best idea, just trying to find some middle ground.   
>> Thoughts?
>>
>> -David
>>
>>
>