-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David,
> [cut.] > > Sorry I wasn't more specific last night at 2:00 am :-). I need more scm > context to understand. I'm assuming something like svn with > > +tags > +root-1.0 (1.0) > +A(1.0) > \B(1.0) > +root-1.1 (1.1) > +A(1.0) > \B(1.1) > \root-1.2 (1.1) > +A(1.0) > \B(1.2) > \trunk > \root(1.2-SNAPSHOT) > +A(???? 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???) > \B(1.3-SNAPSHOT) > > I have several assumptions about releasing stuff... > > - development will continue after the release > - therefore the version in "trunk" must be incremented so it's clear > that snapshots are later than the release > - tags should not contain anything with a snapshot version > - releasing will create a tag of what's been released > - tagging for release creates a copy of an entire svn subtree, not a > copy with stuff removed. > > I see several problems with the svn tree I sketched above: > - there are 3 or 4 copies of A claiming to be version 1.0 > - there is no plausible version for trunk/root/A > - in tags, the version of root doesn't match the end of the directory > name. (there are 2 version 1.1 roots) > > I must not be understanding something basic about what you are > proposing.... I'm probably beating a long-dead horse but could you > please be even more specific about what scm operations you want to have > as part of a release and what the scm repo looks like afterwards? Like Ralph, I have no problem with my scm (which is indeed svn). I also want to maintain versions of modules and have the problems that when I change a version I typically have to change this in all other POMs pointing to the module that changed version. Besiders there can be excuses where a dependency version remains unchanged, so no automatism that release-plugin could guess. And I want to keep modules unchanged in the tree. In my case they would NOT have to be rebuild but that does NOT matter to me. Maintaining these redundant versions is hell if you do it by hand. I have some hacky tools but it could be so easy if you could just omit the version in the dependencies of my local pom.xml's. To answer the SCM-structure question: There maybe some good conventions but SVN gives you a lot of flexibility in whatever you do. I personally always have a flat list of all my modules in tags and then have the according module copied (tagged) there named by its version. I never think that release-plugin has to deal with all possible ways that users can do their release-management. It has to go some way and there will always be people that want it different so I think the release-plugin is NOT the magic answer to all of our problems. > > thanks > david jencks Regards Jörg -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoLGWUACgkQmPuec2Dcv/9MggCbBGoMTwZOct1/WiOBUjPmUoxa SQYAn2+uQ6MPAWWSSuUPyX9oK0wtr9hV =YdFZ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
