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: One version for specs
Date Tue, 03 Oct 2006 17:15:05 GMT

On Oct 2, 2006, at 1:35 PM, David Blevins wrote:

>
> On Oct 2, 2006, at 1:07 PM, Jason Dillon wrote:
>
>> The main problem with compromise in this case... (not that I am  
>> unwilling to do so), is that it appears that _any_ compromise  
>> results in the same problem which I am trying to lead us away  
>> from.  That problem being a complicated build and release process  
>> due to needing deep insight into the dependencies of each spec (or  
>> in your example, the groups of specs).
>
> No, I wasn't advocating groups of specs.  Was more saying "let's  
> just delete these specs from trunk" or otherwise get rid of them  
> and leave only the specs that change and do the one version number  
> thing.  The code is tagged, so it's safe.  Perhaps the issue is  
> that we don't need these unchanging modules in trunk in the first  
> place.  And just so you don't think I'm ignoring pom changes, the  
> poms for the modules I listed are stable to (no deps on anything  
> that's changed).
>
> Thoughts?

Thoughts?

Yank these from trunk as they haven't changed in 2+ years?

ejb
servlet
jms
transaction
connector
qname


-David

> -David
>
>>
>> --jason
>>
>>
>> On Oct 2, 2006, at 11:16 AM, David Blevins wrote:
>>
>>>
>>> On Oct 1, 2006, at 4:31 PM, David Jencks wrote:
>>>
>>>> In any case PLEASE think about this and make your opinion known  
>>>> soon.
>>>
>>> If we could at least make a compromise that'd be very great, all  
>>> or nothing is not the only way.
>>>
>>> Maybe we could just remove these core specs from trunk or  
>>> something (we have several tags):
>>>
>>>  ejb
>>>  servlet
>>>  jsp
>>>  jms
>>>  transaction
>>>  connector
>>>  qname
>>>
>>> If all the rest became "one version number" specs released at the  
>>> pace of the most changing spec, that'd still be less desirable  
>>> but be at least better.
>>>
>>> Maybe not the best idea, just trying to find some middle ground.   
>>> Thoughts?
>>>
>>> -David
>>>
>>>
>>
>


Mime
View raw message