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: One version for specs
Date Tue, 03 Oct 2006 17:31:27 GMT
Can we think carefully about complexity for a second and agree that  
the two models under discussion are

trunk/<individual specs at same SNAPSHOT version>
branches/<version>/<all the individual specs at that SNAPSHOT version>
tags/<version>/<all the individual specs at that non-SNAPSHOT version>


and
<each spec>/[trunk, branches/<version>, tags/<version>]

(in the 2nd choice each spec must be built and released individually  
by itself, there is no "build all the specs" pom)

and that any other choices are going to make releasing anything  
correctly 120% impossible?  We already have a system that doesn't  
work, thinking up more and more complicated choices is not going to  
result in ever releasing anything correctly.

I'll repeat that philosophically I prefer the second solution but I  
don't think we have the attention span as a project to make it work  
so I'm voting for the first choice.  I know if I was in charge of  
releasing the specs I would mess up the second choice for sure but I  
might be able to make the first choice work.  If only half the specs  
are in trunk I wouldn't even try to build the specs myself locally.

thanks
david jencks

On Oct 3, 2006, at 10:15 AM, David Blevins wrote:

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