> > I do like your proposal but am curious to why you say it must change. > > 1. Theory and project lifecycle > > A tag encompasses the whole source tree, i.e. all 3 projects request, > autotag and tiles would be present in each of the 3 tags request-1.0.0, > autotag-1.0.0, and tiles-3.0.0.
That's not necessarily how it works. Each project in trunk comes with its own scm details, (also maven-release-plugin can be configured using remoteTagging=false). It's common enough scenario and i can't see any convention one way or the other. When you run mvn release:prepare it can copy only that project into the tags directory. For example a mvn release:prepare on framework/trunk/tiles-request can copy it to framework/tags/tiles-request-1.0 where the latter folder would contain only tiles-request stuff. > Of course subversion can technically support whatever you want, but that > is the convention behind the branches/tags/trunk structure, and people > will expect us to adhere to it (starting with git-svn). I don't think subversion or maven-release-plugin is a problem here. I see tags of subprojects often enough in tags/ to be uncertain of what's convention or not, and there's enough examples within apache eg aries, avalon/excalibur, cocoon, continuum, empire-db, mahout, etc. > It's not a big issue when talking about tags, because tags are supposed > to be immutable. The problem is more significant when talking about > branches. > Suppose you fix a bug in TILES_3_0_X and another in REQUEST_1_0_X, you > don't have a common source tree with both bugs resolved. This isn't a problem if tags and branches only contain the specific subproject. > 2. Tooling > > We're using maven, which relies heavily on conventions. Usually you can > use your own conventions with some effort, but that creates larger poms > and more difficult to maintain. It is a situation that's often needed when you don't autoVersionSubmodules (which is the convention oddly enough). Like contrib, impl, or plugin subprojects often need extra releases made. For example what if there's enough bugfixes in tiles-autotag-freemarker that warrants a 1.0.1 release, we're not forced to release all of tiles-autotag as 1.0.1. (although some rules for semantic versioning would be wise if we're going to do individual releases). but does this mean that we therefore also need trunk|tags|branches under tiles-autotag-freemarker? The reason i do like the changes you've already made is because we already have "framework" above trunk/ and it doesn't make sense to have request and autotag underneath that. The new structure does make a lot more sense. But for such a big change would it not have been better to discuss it beforehand? I certainly don't take all this for granted and I can't remember (i haven't yet searched this list) if were there any remarks from Antonio on the topic earlier on? (he did most of the work while it was all in the sandbox and must have had thoughts on all this). ~mck -- "Physics is to math what sex is to masturbation." Richard Feynman | http://github.com/finn-no | http://tech.finn.no |
signature.asc
Description: This is a digitally signed message part
