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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
