You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by sverhagen <ve...@sander.com> on 2008/12/10 00:07:05 UTC
Up-to-date release
Hi. We heavily use the Maven release plugin.
Following scenario:
* Developers update from SVN
* Developer 1 commits a change
* Developer 2 commits a change and releases ("mvn release:prepare")
Because developer 2 does not explicitly update from SVN, the change from
developer 1 will not be in the release. Hard to track down, hard to detect.
I've attempted adding stategies to check if the releasing developer
(developer 2) is up-to-date, using buildnumber-maven-plugin. Unsuccessful,
since release plugin does its own local modifications prior to running the
buildnumber plugin.
I know I can make a nice shell script to check this, but I would like to
configure it in Maven, to make things mandatory and reproducible.
Thanks for your ideas!
Sander.
--
View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20925759.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by Clint Gilbert <cl...@childrens.harvard.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm subscribed to this bug:
http://jira.codehaus.org/browse/SCM-406
Lots of people are complaining, but sadly there are no answers so far.
The problem seems to be that when doinf releaase:prepare, the release
plugin tries to commit the current working copy as a tag, instead of
copying a remote URL. SVN < 1.5 allows this, SVN 1.5.x apparently does not.
There's bound to be a workaround. Someone suggested locking the trunk
while the release plugin runs; I have no idea how feasible that would be.
sverhagen wrote:
>
> Stephen Connolly-2 wrote:
>> Use Subversion 1.5
>>
>> the release plugin is broken with svn 1.5 and will not make a release if
>> the
>> entire workspace is not 100% up to date
>
> Hi, Stephen. Thanks for your prompt reply, but I tend to disagree. I am
> having exactly the problems that I described while being on 1.5.0 (see
> below). There is some regression in Subversion, I suppose, I have had people
> downgrade back to 1.5.0 for not being to able to release. Would you have the
> JIRA issue for what you're referring to?
> Thanks, Sander.
>
> "svn --version"
> svn, version 1.5.0 (r31699)
> compiled Jun 23 2008, 12:59:48
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEUEARECAAYFAkk/R68ACgkQ0GFaTS4nYxsnTACXWccUsTP0D7DPnN8fxTOgJE07
PgCfQjLqI5xMbRpfhMn/Zac5ktQnJhw=
=enWc
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
Stephen Connolly-2 wrote:
>
> Use Subversion 1.5
>
> the release plugin is broken with svn 1.5 and will not make a release if
> the
> entire workspace is not 100% up to date
Hi, Stephen. Thanks for your prompt reply, but I tend to disagree. I am
having exactly the problems that I described while being on 1.5.0 (see
below). There is some regression in Subversion, I suppose, I have had people
downgrade back to 1.5.0 for not being to able to release. Would you have the
JIRA issue for what you're referring to?
Thanks, Sander.
"svn --version"
svn, version 1.5.0 (r31699)
compiled Jun 23 2008, 12:59:48
--
View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20925991.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by Stephen Connolly <st...@gmail.com>.
Use Subversion 1.5
the release plugin is broken with svn 1.5 and will not make a release if the
entire workspace is not 100% up to date
;-)
(may be fixed in svn 1.5.4)
2008/12/9 sverhagen <ve...@sander.com>
>
> Hi. We heavily use the Maven release plugin.
> Following scenario:
> * Developers update from SVN
> * Developer 1 commits a change
> * Developer 2 commits a change and releases ("mvn release:prepare")
>
> Because developer 2 does not explicitly update from SVN, the change from
> developer 1 will not be in the release. Hard to track down, hard to detect.
>
> I've attempted adding stategies to check if the releasing developer
> (developer 2) is up-to-date, using buildnumber-maven-plugin. Unsuccessful,
> since release plugin does its own local modifications prior to running the
> buildnumber plugin.
>
> I know I can make a nice shell script to check this, but I would like to
> configure it in Maven, to make things mandatory and reproducible.
>
> Thanks for your ideas!
>
> Sander.
> --
> View this message in context:
> http://www.nabble.com/Up-to-date-release-tp20925759p20925759.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
RE: Up-to-date release
Posted by Todd Thiessen <th...@nortel.com>.
I have never used that myself either. My impression is that it locks
only a single file though, not the entire repository. Perhaps someone
more experienced in this area could comment.
---
Todd Thiessen
> -----Original Message-----
> From: sverhagen [mailto:verhagen@sander.com]
> Sent: Monday, December 15, 2008 2:18 PM
> To: users@maven.apache.org
> Subject: RE: Up-to-date release
>
>
>
> Todd Thiessen wrote:
> >
> > Unfortunately, I don't believe there is a way to completely
> ensure an
> > up-to-date work area. A commit could happen just after you do the
> > update so you can still release what is not really in trunk.
> >
> >
>
> That's what I always thought this was for:
>
> "useEditMode:
> Whether to use "edit" mode on the SCM, to lock the file for
> editing during SCM operations."
>
> (Although we don't use it, apparently we're taking that chance.)
> --
> View this message in context:
> http://www.nabble.com/Up-to-date-release-tp20925759p21019987.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
Todd Thiessen wrote:
>
> Unfortunately, I don't believe there is a way to completely ensure an
> up-to-date work area. A commit could happen just after you do the update
> so you can still release what is not really in trunk.
>
>
That's what I always thought this was for:
"useEditMode:
Whether to use "edit" mode on the SCM, to lock the file for editing during
SCM operations."
(Although we don't use it, apparently we're taking that chance.)
--
View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p21019987.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Up-to-date release
Posted by Todd Thiessen <th...@nortel.com>.
> -----Original Message-----
> From: sverhagen [mailto:verhagen@sander.com]
> Sent: Saturday, December 13, 2008 8:31 AM
> To: users@maven.apache.org
> Subject: Re: Up-to-date release
>
>
>
> Wendy Smoak-3 wrote:
> >
> > I still tend to favor communication and a quiet period when
> a release
> > is going on, as well as keeping a close eye on the commits list to
> > make sure nothing slips in (or slips _by_, as in this case.)
> >
>
> We have a distributed team, and we release "often" and
> "small". Many changes are unrelated but may still be in the
> same module, and Maven safeguarding an up-to-date work area
> would just suffice.
Unfortunately, I don't believe there is a way to completely ensure an
up-to-date work area. A commit could happen just after you do the update
so you can still release what is not really in trunk.
The only way that I can see you doing what you want would be to do a
revision copy of trunk to tags. You just have to be aware that what is
in your working copy may not be what actually gets released.
I think no matter which way you go, Wendy's advice is still sound.
---
Todd Thiessen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
Wendy Smoak-3 wrote:
>
> I still tend to favor communication and a quiet period when a release
> is going on, as well as keeping a close eye on the commits list to
> make sure nothing slips in (or slips _by_, as in this case.)
>
We have a distributed team, and we release "often" and "small". Many changes
are unrelated but may still be in the same module, and Maven safeguarding an
up-to-date work area would just suffice. We have a lot of process and
tooling and communication in place, but if it's not needed, it's overhead,
and we want to cut it. (Our devs are tangled up in overhead a lot of their
time already, so whatever we can cover with improving our tooling is very
welcome.)
--
View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20990217.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, Dec 9, 2008 at 6:31 PM, sverhagen <ve...@sander.com> wrote:
> Yours fails on inconsistent pom.xml. In my scenario I can tell you that the
> POM did not change due to the work of either one of the developers; the
> sources changed.
>
> Also, yours fails on commiting something to the trunk, rather than making
> the tag.
Thanks for pointing that out-- making a change to the pom instead of
the code wasn't a good test. I re-did it after making a change to the
code from a different checkout, and release:prepare succeeded.
I still tend to favor communication and a quiet period when a release
is going on, as well as keeping a close eye on the commits list to
make sure nothing slips in (or slips _by_, as in this case.)
Still it's a good one to be aware of and to put in JIRA, if it's not
already there.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
Thanks for your quick response.
Wendy Smoak-3 wrote:
>
> [ERROR] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Unable to commit files
> Provider message:
> The svn command failed.
> Command output:
> svn: Commit failed (details follow):
> svn: Your file or directory 'pom.xml' is probably out-of-date
> svn: resource out of date; try updating
>
Yours fails on inconsistent pom.xml. In my scenario I can tell you that the
POM did not change due to the work of either one of the developers; the
sources changed.
Also, yours fails on commiting something to the trunk, rather than making
the tag.
I ended up with an issue being fixed in a revision before a release, the
release being on the production system, and the fix missing from the
production system. I am *very* concerned about this opportunity for errors.
Except for the release tag, my whole scenario plays on trunk.
Wendy Smoak-3 wrote:
>
> Still, I'd suggest:
> Developer A communicates that a release is in progress/code freeze.
> Developer B holds commits, or one of them works on a branch.
>
Their work was sequential in time, not parallel.
If the release plugin would've been bullet proof in this regard, as I always
expected it to be (until now), communication would not have been necessary.
(I agree that it would have been, when they'd been working on the same thing
at the same time. No argument.)
--
View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20926113.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by Wendy Smoak <ws...@gmail.com>.
On Tue, Dec 9, 2008 at 6:07 PM, sverhagen <ve...@sander.com> wrote:
>
> Hi. We heavily use the Maven release plugin.
> Following scenario:
> * Developers update from SVN
> * Developer 1 commits a change
> * Developer 2 commits a change and releases ("mvn release:prepare")
>
> Because developer 2 does not explicitly update from SVN, the change from
> developer 1 will not be in the release. Hard to track down, hard to detect.
Have you actually had this happen? I'm pretty sure it's going to
complain that the working copy isn't up to date when it tries to
tag...
Yep, it does:
$ mvn release:prepare
...
[INFO] Checking in modified POMs...
[INFO] Executing: svn --non-interactive commit --file
/tmp/maven-scm-1832181566.commit --targets
/tmp/maven-scm-10681-targets
[INFO] Working directory: /private/tmp/hello1
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: Your file or directory 'pom.xml' is probably out-of-date
svn: resource out of date; try updating
This is with Subversion 1.4.4 on OS X.
Still, I'd suggest:
Developer A communicates that a release is in progress/code freeze.
Developer B holds commits, or one of them works on a branch.
--
Wendy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by John Stoneham <ly...@lyrically.net>.
On Thu, Dec 25, 2008 at 10:20 AM, sverhagen <ve...@sander.com> wrote:
> Two questions:
> - Why is MANIFEST.MF version controlled to begin with. Isn't it a generated
> file?
Depends on your workflow. In OSGi the manifest controls the classes
your bundle can even use, and Eclipse's PDE tooling modifies the
manifest directly as it is independent of Maven. It's much easier to
simply control the manifest than to try to constantly port manifest
changes over into POM changes only to regenerate the manifest.
Certainly the manifest that ends up in the build is somewhat different
than what's controlled - 72-character wrapping, additional Maven-added
stuff, etc. - but the template at least is often controlled in order
to work more smoothly with other tooling.
> - Don't you update MANIFEST.MF on every build? We do so, since we also
> appreciate to have package details available when a developer is just
> experimenting with something that is a snapshot
It's no problem to have Maven touch this file or do whatever with it
during the build. But often as I said, a sort of template is often
controlled directly.
- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
John Stoneham wrote:
>
> in case
> the preparation goals update some files on purpose (for example, we
> use OSGi, and use the preparation goals to update our MANIFEST.MF
> files so the versions match the POM versions).
>
Two questions:
- Why is MANIFEST.MF version controlled to begin with. Isn't it a generated
file?
- Don't you update MANIFEST.MF on every build? We do so, since we also
appreciate to have package details available when a developer is just
experimenting with something that is a snapshot
--
View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p21168180.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by John Stoneham <ly...@lyrically.net>.
On Wed, Dec 10, 2008 at 9:12 AM, Todd Thiessen <th...@nortel.com> wrote:
> This causes fewer "freezes" of the main trunk. Someone can do a formal
> release and other devs can still commit to trunk and only see those
> changes in SNAPSHOT versions where they can get some soak before making
> a formal release. Once the release checkout is made, what is in the
> working copy should be exactly what is released.
Yep. Importantly, it needs to be what's in the working copy - in case
the preparation goals update some files on purpose (for example, we
use OSGi, and use the preparation goals to update our MANIFEST.MF
files so the versions match the POM versions).
If this isn't going to work in SVN going forward, we may need to
introduce an additional (optional?) trunk commit into the release
process prior to the tag. (How does this work in other SCMs?)
- John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Up-to-date release
Posted by Todd Thiessen <th...@nortel.com>.
Comments within.
Anyone else have thoughts on this?
---
Todd Thiessen
> -----Original Message-----
> From: sverhagen [mailto:verhagen@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Up-to-date release
Posted by Todd Thiessen <th...@nortel.com>.
Comments within.
---
Todd Thiessen
> -----Original Message-----
> From: sverhagen [mailto:verhagen@sander.com]
> Sent: Tuesday, December 09, 2008 6:07 PM
> To: users@maven.apache.org
> Subject: Up-to-date release
>
>
> Hi. We heavily use the Maven release plugin.
> Following scenario:
> * Developers update from SVN
> * Developer 1 commits a change
> * Developer 2 commits a change and releases ("mvn release:prepare")
>
> Because developer 2 does not explicitly update from SVN, the
> change from developer 1 will not be in the release. Hard to
> track down, hard to detect.
Why would you expect developer 1's changes to be in the release? If
developer 2 does a check out, makes a change then builds a release he
should NOT expect developer 1's changes since he never performed an
update. The release plugin should NOT do an update automatically. At
most this should be an option but I think it is just fine having
developer 2 having to run a svn update if he/she wishes to get the
latest commits.
This causes fewer "freezes" of the main trunk. Someone can do a formal
release and other devs can still commit to trunk and only see those
changes in SNAPSHOT versions where they can get some soak before making
a formal release. Once the release checkout is made, what is in the
working copy should be exactly what is released.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by sverhagen <ve...@sander.com>.
Christian Schulte wrote:
>
> The maven-scm-plugin may be helpful.
>
> <http://maven.apache.org/scm/maven-scm-plugin/update-mojo.html>
>
My first response to this was: didn't he read my comment:
> I've attempted adding stategies to check if the releasing developer
> (developer 2) is up-to-date, using buildnumber-maven-plugin. Unsuccessful,
> since release plugin does its own local modifications prior to running the
> buildnumber plugin.
>
But SCM may actually be a lot less aggressive than buildnumber. So it's
actually a great idea to use SCM instead!
Which is still a bit tricky is that it will update and silently leave behind
conflicts. For instance, I just tried a release without having updated my
POM properly, which resulted in having:
pom.xml (mangled)
pom.xml.mine
pom.xml.r14815
pom.xml.r14818
This works well: build fails anyway on the mangled pom.xml which is a sign
to the developer that he should have updated ;-)
This will be more problematic: something else than the POM is mangled and
does not get picked up by compile or test, and goes into my release :-(
All'n'all... a good start... still thinking on it!
Thanks for that.
--
View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20986559.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Up-to-date release
Posted by Christian Schulte <cs...@schulte.it>.
sverhagen schrieb:
> Hi. We heavily use the Maven release plugin.
> Following scenario:
> * Developers update from SVN
> * Developer 1 commits a change
> * Developer 2 commits a change and releases ("mvn release:prepare")
>
> Because developer 2 does not explicitly update from SVN, the change from
> developer 1 will not be in the release. Hard to track down, hard to detect.
The maven-scm-plugin may be helpful.
<http://maven.apache.org/scm/maven-scm-plugin/update-mojo.html>
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org