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