Todd Thiessen wrote: > > You said it yourself. The actual release corresponds to the appropriate > tag so it is very easily reprodicible. "What is actually inside the > release" is in the tag. There is no need for any compares of SVN > revisions. >
If you have commits x, y, z between two subsequent releases from the exact trunk, you can easily use the SVN log entries to see what has changed. If you don't use the exact trunk, you can indeed compare the two tags of these releases, but you are stuck with looking at bare file compares, instead of proper SVN log entries. Todd Thiessen wrote: > > I believe the main reason why the "trunk" contains the actual release > information is because tags are sometimes not allowed to be modified. So > you wouldn't be able to copy to your tag, and then modify the POM to > indicate a released version. > You would want not to modify the tag, instead make a tag of a non-commited trunk. Anyway, this is arguing into a direction that was my whole point I didn't want to go, to begin with :) Todd Thiessen wrote: > > The release plugin asserts on local modifications "that are not > committed". This means that anything that is in the working copy is in > the trunk. That is the point in doing so. > I'm taking the risk (again?) of repeating myself over and over. But...: What is the point in doing this (supposedly reproducability?) if the next thing is that you are allowed to have *any* sort of mix of revisions between files (which would only be reproducible if you had any sort of log of how you got to that mix of revisions between files, which you don't have, hence I still consider it not reproducible, and therefore evil). Todd Thiessen wrote: > > This is a good thing > since now other developers can commit content which isn't release ready. > I agree that other developers should be able to do that. In our organisation we've chosen to release from branches, if the trunk is cluttered with unverified changes. The 'releaser' looks at the SVN log of the trunk to make the assessment for this. Todd Thiessen wrote: > > It is the > responsibility of the releaser to ensure that what ever is supposed to > be in the release, is in his/her checkout. > Yes, but we want to do that in a way that's properly reproducible through SVN log entry trails. Hence, making a branche of the trunk at the latest point of which you want *everything* in the release. On the branche you merge everything from the trunk that's needed in the release. I understand that what you describe "works" as well, but I feel it's a risky shortcut in the 'reproducibility' department. I also feel that it's a matter of loosing track of good SCM behavior because "your other tool" (Maven in this case) allows you to (and yes, from a Maven point of view there may be nothing wrong with doing so). -- View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p21168161.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
