geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: Geronimo Specs 1.1-SNAPSHOT
Date Sun, 29 Jan 2006 23:13:29 GMT

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 :-)

thanks
david jencks

>
> -David
>


Mime
View raw message