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.
-David
>
> 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 (http://marc.theaimsgroup.com/?l=geronimo-
>>> 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