Re: Who cares? [was: [DISCUSS] specs versioning]

[Donald Woods]

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.

-Donald


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.

--jason

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?

smime.p7s
Description: S/MIME Cryptographic Signature