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.
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.
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. In my
opinion, this 'fully corresponding' only makes sense if everything is on the
same revision (for instance the head). As far as I am concerned it does not
need to be head, but having a mixture of revisions in your work area and
releasing it makes no sense to me, whatsoever.
(Where I'm talking about 'trunk' and 'head of trunk', this could just as
well have been some branch that I'm releasing from. Same story.)
Best regards, Sander.
--
View this message in context:
http://www.nabble.com/Up-to-date-release-tp20925759p20986493.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
