Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of david.blevins@visi.com
 designates 208.42.156.2 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v746.2)
In-Reply-To: <D4B24EE7-2AE3-4160-A1D4-3637A478061A@yahoo.com>
References: <43DBBEA8.9010805@toolazydogs.com>
 <559F5BF2-2C6A-43C3-9A72-AE4DA25EB6E4@yahoo.com>
 <43055F1B-CE88-48C3-A756-C2C80B633DEA@visi.com>
 <F6CD071B-0D20-4082-A925-04C59283ABBB@yahoo.com>
 <CA0EFE6E-EF59-46B3-8FDC-A030405B6D52@visi.com>
 <D4B24EE7-2AE3-4160-A1D4-3637A478061A@yahoo.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <100AF30C-8201-495A-967B-9B97CF0F1E0E@visi.com>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: Geronimo Specs 1.1-SNAPSHOT
Date: Sun, 29 Jan 2006 16:45:54 -0800
To: dev@geronimo.apache.org


On Jan 29, 2006, at 3:13 PM, David Jencks wrote:

>
> On Jan 29, 2006, at 2:35 PM, David Blevins wrote:
>
>> On Jan 29, 2006, at 2:01 PM, David Jencks wrote:
>>
>>>
>>> On Jan 29, 2006, at 1:41 PM, David Blevins wrote:
>>>
>>>> On Jan 28, 2006, at 11:51 AM, David Jencks wrote:
>>>>
>>>>> On Jan 28, 2006, at 10:57 AM, Alan D. Cabrera wrote:
>>>>>
>>>>>> I've updated the trunk of Geronimo Specs to 1.1-SNAPSHOT.  The  
>>>>>> thinking is that we update the versions of all the spec jars  
>>>>>> in tandem.  The rational for that is that end developers will  
>>>>>> not want to pick and choose what got updated in our collection  
>>>>>> of spec jars but, instead, will just want the latest and  
>>>>>> greatest version for the entire set.
>>>>>>
>>>>>>
>>>>> IMO a more important reason is that we are aggregating all the  
>>>>> specs into an uber-spec-jar that contains everything.  In order  
>>>>> for this jar to have a meaningful version all the things of  
>>>>> which it is built have to have the same version.  In any case,  
>>>>> I certainly agree this is the right thing to do.
>>>>>
>>>>
>>>> I see and understand those points, but I would like to add the  
>>>> points that:
>>>>
>>>>  1. issuing new versions of jars that don't change creates a  
>>>> confusing mess in public repos and classpaths.
>>>>  2. snapshots and new jars off all the specs is a terrible way  
>>>> to deal with one or two edge cases of jars that change.
>>>>
>>>> But as opinions are cheap, I figured I'd actually revaluate  
>>>> where we are at in concrete terms.  I grabbed all the source  
>>>> from 2 years ago, 10 months ago (near passing the cts), and now  
>>>> then stripped out all the comments and diff'ed them.  Here is  
>>>> what I found.
>>>>
>>>> no code changes in 2 years:
>>>>  - ejb
>>>>  - j2ee-connector
>>>>  - j2ee-deployment
>>>>  - j2ee-management
>>>>  - jms
>>>>  - jsp
>>>>  - jta
>>>>  - servlet
>>>>
>>>> no code changes in 10 months:
>>>>  - activation
>>>>  - jaxr
>>>>  - qname (new)
>>>>  - saaj (new)
>>>>  - jaxrpc (new)
>>>>
>>>> These two seem to have changed the most:
>>>>  - j2ee-jacc (no change since M5)
>>>>  - javamail (problem child)
>>>>
>>>>
>>>> IMHO, doesn't make sense to keep pushing new versions into the  
>>>> public for stuff that doesn't change.
>>>>
>>>> What do others think?
>>>
>>> You left out the corba spec module, whose changes precipitated  
>>> the current brouhaha.
>>>
>>> I'm fine with either:
>>>
>>> 1. dropping the uber-spec-jar entirely
>>> 2. keeping versions of every spec jar in sync.
>>>
>>> I might be willing to consider another alternative if someone  
>>> would explain what it was, and how the uber-spec-jar version  
>>> would be determined after each of these individual events, each  
>>> of which requires re-releasing the uber-spec-jar:
>>>
>>> individual spec jar A changes to say 1.1
>>> individual spec jar B changes to say 1.1
>>> individual spec jar A changes to say 1.2
>>>
>>> So far I haven't seen any actual other proposals to (1) or (2)
>>>
>>
>> I think we should just push new version of a spec jar at an  
>> appropriate time when said jar changes.  For the uber-spec jar we  
>> can just push a new version when a dep spec jar changes.
>>
>> Seem reasonable?
>
> To me this is not a proposal until you specify what the uber spec  
> jar revision is after each of the changes I mentioned.  An  
> algorithm would be even better :-)
>
> So, not yet :-)
>

Sure.  Everything has it's own version number which will be  
incremented by one.

-David