geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Who cares? [was: [DISCUSS] specs versioning]
Date Tue, 12 Dec 2006 19:13:45 GMT

On Dec 12, 2006, at 10:09 AM, Donald Woods wrote:

> Hmmm.... sounds like a good approach - only have the specs in trunk  
> or a branch that are undergoing changes and all the others live in  
> tags until  changes are needed.
> That would make it easier for anyone trying to find the latest  
> specs not to get confused with all of them being in trunk, but only  
> one or two of them being published....
> That would make builds easier too, since running mvn under the  
> specs directory would only be building the few specs that are there  
> and they would each have their own version number.

I like that approach.  Posted the same idea in October when we had  
this discussion.

On Oct 2, 2006, at 1:35 PM, David Blevins wrote:
> Was more saying "let's just delete these specs from trunk" or  
> otherwise get rid of them and leave only the specs that change  
> [....]  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.

I still like the idea.


> Jason Dillon wrote:
>> On Dec 11, 2006, at 8:23 PM, David Blevins wrote:
>>> Just to quietly raise my hand, we used to do option 2 on 1.0-M1  
>>> through 1.0-M5 and I was release manager nearly all of those.  I  
>>> advocated using one version for all specs.  I eventually grew to  
>>> dislike that ( 
>>> dev&m=113857091823325&w=2).
>>> I understand institutional memory is short if people really want  
>>> to do the one version thing again, that's cool.  I just want to  
>>> go on record as saying I think the way we've attempted the one  
>>> version for each approach also turned out to be flawed.  We  
>>> should have marked all the dependencies of each spec with  
>>> '<scope>provided' shutting off maven's transitivity which would  
>>> fix every issue I'm aware of with managing relationships between  
>>> specs.
>> Thought I think it is odd, to *move* code from a branch to a tag,  
>> and then back to a branch, this might be a better solution for  
>> these specs that will never change, or change like every 5 years  
>> er something.
>> Or maybe... the problem is really to tool we are using, or the way  
>> we are using that tool.  Perhaps if mvn could handle building a  
>> release of a set of modules in one step and each of theses modules  
>> had its own trunk/tags/branches then none of this will matter?
>> --jason

View raw message