geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Woods <>
Subject Re: Who cares? [was: [DISCUSS] specs versioning]
Date Tue, 12 Dec 2006 18:09:48 GMT
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.


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