Ralph Goers schrieb: > On May 13, 2009, at 5:09 PM, Christian Schulte wrote: > >> Ralph Goers schrieb: >>> So the tree really looks like: >>> >>> +tags >>> +root-1.0 (trunk revision 1) >>> +A(1.0) >>> +B(1.0) >>> +root-1.1 (trunk revision 2) >>> +A(1.0) >>> +B(1.1) >>> +root-1.2 (trunk revision 3) >>> +A(1.0) >>> +B(1.2) >>> /trunk at revision 4 >>> +root(1.2-SNAPSHOT) >>> +A(1.0) >>> +B(1.3-SNAPSHOT) >>> >>> This assumes that A has not been modified since its initial release >>> and B is currently under development and has not been released. >>> >> What stops a developer from making changes to A(1.0) on trunk, >> rebuilding locally - that is - overwriting release artifacts with >> something different in the local repository, and then later on even >> commit those changes forgetting to increase the version to a >> snapshot ? >> Discipline ? >> > > Actually, this isn't at all the way we do releases. This was my > response to David's hypothetical scenario which didn't make any sense > to me. All I did was clean it up. > > What we actually do looks more like: > > +tags > +library-1.0.0 (on branch-library-1.0) pom version is 1.0.0 > +A(1.0.0) > +B(1.0.0) > +C(1.0.0) > +library-1.0.1 (on branch-library-1.0) pom version is 1.0.1 > +A(1.0.0) > +B(1.0.1) > +C(1.0.0) > +library-1.1.0 (on branch-library-1.1) pom version is 1.1.0 > +A(1.0.0) > +B(1.1.0) > +C(1.1.0) > +branches > +branch-library-1.0 (pom is still 1.0.1 - no work in progress on > branch) > +A(1.0.0) > +B(1.0.0) > +C(1.0.0) > +branch-library-1.1 (pom is 1.1.0-SNAPSHOT) (work in progress) > +A(1.0.0) > +B(1.1.0) > +C(1.1.1-SNAPSHOT) > /trunk (library-1.2-SNAPSHOT) (Work in progress) > +A(1.1.0-SNAPSHOT) (new work) > +B(1.1.0) > +C(1.2.0-SNAPSHOT) (work from branch-library-1.1 has been merged) > > The point here is not to debate the "right" or "wrong" way to manage > projects. It is what it is and it accomplishes our goals. The issue is > that the release plugin (at least the last time I reviewed it) > mandates that there is only one right way to do a release. As the > debate on Legal discuss last week shows this isn't necessarily the > case. I would suggest that the release plugin almost needs a lifecycle > of its own where the actual work is accomplished through plugins. If > things have changed significantly let me know and I'd be happy to look > at it again. > > Ralph >
Some developers of the release-manager can better answer this. The release manager uses its own phases internally, I think. <http://svn.apache.org/viewvc/maven/release/tags/maven-release-2.0-beta-9/maven-release-manager/src/main/java/org/apache/maven/shared/release/phase/> Hooking something in there may already be possible easily but I don't know for sure. My question may have sounded rhetorically but I really meant that. You could of course manage commit rights with subversion so that whenever someone mistakenly would try to commit to that release version on trunk, subversion could simply disallow that. So a developer would at least have to ask someone for permission to do so. I just don't get the point for what all this additional effort is good for. Really only to not release artifacts whose code did not change ? As I see it, that only introduces additional complexity without any advantage. Indeed it introduces some disadvantages every developer must be made aware of and you cannot use quite well working maven tooling that way. Not because this tooling behaves wrong, IMHO. The same applies to automatically discovering the parent pom. That's constantly changing artifacts without anyone noticing it, somehow. At least in all local repositories. It does not matter if there are any code changes. Changing poms is the same as changing code, IMHO. I would just say that it takes less than a week until every developer has its own releases in the local repository and noticing that is really not that easy. For me such setup would not work at all since the CI server not only builds artifacts whenever someone committed something, but forcibly runs builds every few days or so. So for me that would just mean that the CI server would constantly deploy differing release artifacts. Even worse, those release artifacts contain a reference to a snapshot parent pom which introduces additional problems. Non-reproducible. Don't get me wrong. I still think you have really good reasons for doing things the way they are done. I just don't get it. I don't even see a single advantage but a lot of disadvantages. I am not saying that there may not be any advantages. -- Christian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
