geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Geronimo Specs 1.1-SNAPSHOT
Date Mon, 30 Jan 2006 00:45:54 GMT

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



Mime
View raw message