Comments within. Anyone else have thoughts on this?
--- Todd Thiessen > -----Original Message----- > From: sverhagen [mailto:verha...@sander.com] > Sent: Friday, December 12, 2008 8:47 PM > To: users@maven.apache.org > Subject: RE: Up-to-date release > > > Hi, again. > > > Todd Thiessen wrote: > > > > Why would you expect developer 1's changes to be in the release? > > > > Because the whole point of making releases is them to be reproducible. > If the contents of the release depends on the steps my dev > did or did not take, it's hardly reproducible. > > Now, I'll admit that the tag corresponds to the actual > released artifact. So the release itself is reproducible. The > path to it is much more difficult, though. Namely, what is > actually inside this release I can only learn from doing a > potentially large number of cumbersome compares of SVN > revisions against the tag. 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. > > I'll argue why I had the expectation that the state of the > trunk was to be released, rather than the state of someone's > work area. As you all know, Maven is doing three SVN > operations when releasing: > 1. Change trunk to have the release version number > 2. Copy to tag > 3. Change trunk to have next development snapshot > number number If step 1 was not designed to get into a state > that is exactly what is going to be in the release, it should > have left out. Maven could have gone to the tag directly. > Doing so would have made the statement that the tag and only > the tag shows the state of the release. 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. I do agree with you that committing a "released" version of the POM into trunk is a bit confusing. I wish that the changes were not committed. But others have mentioned that not all SCMs may be able to perform a copy with uncommited changes in the working copy. No matter which way you do it (changing the trunk to indicate a released version, or changing this in the tag) either the trunk or the tag will be inconsistent. ie: the trunk will contain a released version in its revision history or the tag will contain a snapshot version. There were some options that were discussed a short while ago in the "Limitation of the Release Plugin" [1] thread. > Additionally, the release plugin asserts on local > modifications. There would have not been any point doing so, > if releases weren't meant to fully correspond to the trunk > that this verification is done against. 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. However, what is in the trunk is not necessarily what is in the working copy. This is a good thing since now other developers can commit content which isn't release ready. ie: it can get some soak as a SNAPSHOT version first. It is the responsibility of the releaser to ensure that what ever is supposed to be in the release, is in his/her checkout. Having the tool automatically pull in updates could get content into a release that was not meant to be there. [1] http://www.mail-archive.com/users@maven.apache.org/msg92959.html --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
