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 22:01:11 GMT

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)

thanks
david jencks

>
> -David
>


Mime
View raw message