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 Sun, 29 Jan 2006 22:35:15 GMT
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?

-David


Mime
View raw message