Re: release-plugin: push changes after perform for DCVS
Chris, it is _my personal_ experience, that running release:perform fails more often than the taging/comitting steps in release:prepare. - E.g. I run release:prepare and some plugins are only activated when performRelease is set (checkstyle, rat, gpg, license-checker). - You may argue that I just should activate the same profiles during preparationGoals (-DperformRelease=true clean verify) and be good. - But we have multi-module builds, where tests takes several hours (a problem of it's own, I know), so teams are not willing to run tests during prepare *and* perform. - I could advise them to run the tests during prepare only, however this feels strange as the binaries are deploy are not the same. - So I advise them to skip tests during prepare (you could even set preparationGoals=clean). - Then you may end with tags which never make it into production as a test broke during release:perform. - While this is no problem, when you only do release builds every other day, other teams want to deploy continuously and then you are left with a lot of non-deployed tags in your SCM after a while (or you would need a procurement mechanism of tags which made it into production). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Mon, Apr 13, 2015 at 3:48 AM, Chris Graham chrisgw...@gmail.com wrote: I'm not actually sure of what problem you're trying to solve here. On Sat, Apr 11, 2015 at 6:49 AM, Mirko Friedenhagen mfriedenha...@apache.org wrote: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. I have a real problem with the word 'probably' here. As there will always be times when that is not the case, when things fail. Sometimes on a permanent basis, sometimes a temporary failure. What appears to be the case here, is that we've come up with a proposed solution to a problem that I have no clear idea about. Can someone please elaborate? What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: release-plugin: push changes after perform for DCVS
Hello Mirko. I've been there too. With builds that take 4-6 hours to run, hundreds of modules, and lots of testing failures, some intermittent, some not. In my case, I had a very tempremental ESB/Process Server's serviceDeploy to contend with. I added a retry option into the was6:serviceDeploy goal to deal with just that. I'll comment along with what you're written below. On Mon, Apr 13, 2015 at 9:04 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Chris, I do wish people would put at least Hi or Hello in front of it. I always makes me think that I'm being spoken down too or told off. it is _my personal_ experience, that running release:perform fails more often than the taging/comitting steps in release:prepare. - E.g. I run release:prepare and some plugins are only activated when performRelease is set (checkstyle, rat, gpg, license-checker). As you say, that all depends on how you run your plugins. I normally -DskipTests=true into one or the othe (prepare or perform). - You may argue that I just should activate the same profiles during preparationGoals (-DperformRelease=true clean verify) and be good. - But we have multi-module builds, where tests takes several hours (a problem of it's own, I know), so teams are not willing to run tests during prepare *and* perform. If you think of the prepare as the SCM operations, and the perform as the real testing stage, then you've got a good (and I think correct) separation. I prefer to run the tests in the perform stage, as they can be re-run. That is why perform *can* be rerun; it was designed to be. - I could advise them to run the tests during prepare only, however this feels strange as the binaries are deploy are not the same. And why I don't. The binaries are different? Why? That aside, running in the perform stage means that you are truly testing the released binaries, no ifs buts or maybes. - So I advise them to skip tests during prepare (you could even set preparationGoals=clean). I do. - Then you may end with tags which never make it into production as a test broke during release:perform. So? Ignoring the fact that perform can be rerun, you're always going to have 'broken' releases. Whether due to broken code or a testing failure (valid or intermittent) or not, you're always going to have to contend with the possibilies of a broken release. I think that you're pushing too much value onto the current working definition of what a release is. A release is a release that matches a SCM tag. That's it. Whether it works or not is yet to be determined. Even *if* it reaches production, that does not meant that it works. Or should have gone to production either... - While this is no problem, when you only do release builds every other day, other teams want to deploy continuously and then you are Well, the fundamental issue here is that of expectations. 4+ hour builds and continuous deployment are pretty much mutually exclusive here. CD here is wishful thinking. Oh, in the WebSphere Process Server sense, after a 4+ hour build, the deployments themselves took 2-3 hours (absolute worst case). In my case, I forced a nightly build. The devs soon learned that things had to be done by the end of the day or else they would not be in the release. left with a lot of non-deployed tags in your SCM after a while (or you would need a procurement mechanism of tags which made it into production). You could equally have a large number of tags that DID make it into production! Again, so what? I introduced the concept of a Platform Release, which was a cherry picking of what versions of what formed a release. - PortalRelease-X.Y.Z.B - a collection of 3-5 Portal ears/wars. - WPSRelease-X.Y.Z.B - a collection of 30 odd EARS, and around 30 odd Testing EARS (Process Server) - WMBRelease-X.Y.Z.B - a collection of 40+ Message Broker BAR files. (Message Broker) etc Each of the XXXRelease projects was a zip file. Then I released the PlatformRelease projects (yes, a cascading release mechanism) that was a zip of zips. That is the binary bundle that was allowed to be deployed. That was what all of the CCB's etc approved. No one really cared about the prior releases, but they were documented should someone need them. If they needed easy access, I'd give them a web apge table/matrix/spreadsheet. I don't see it as an issue. Now, back to the point. I don't think messing with the release mechanism is going to make things any easier, as it's a process issue that you've got to solve. I (think I) understand the issues, sizes and timings of what you've explained above, as it was projects of this size that I've worked with for the last 6 years. However, I do not think that doing a retroactive push is actually going to help, in fact, I think that it's more than likely to complicate matters. Eg, what happens to duplicate tags on separate repos if someone should accidently attempt to push them later on? (might be a bad example)
Re: release-plugin: push changes after perform for DCVS
B On Monday, April 13, 2015, Chris Graham chrisgw...@gmail.com wrote: Hello Mirko. I've been there too. With builds that take 4-6 hours to run, hundreds of modules, and lots of testing failures, some intermittent, some not. In my case, I had a very tempremental ESB/Process Server's serviceDeploy to contend with. I added a retry option into the was6:serviceDeploy goal to deal with just that. I'll comment along with what you're written below. On Mon, Apr 13, 2015 at 9:04 PM, Mirko Friedenhagen mfriedenha...@gmail.com javascript:; wrote: Chris, I do wish people would put at least Hi or Hello in front of it. I always makes me think that I'm being spoken down too or told off. it is _my personal_ experience, that running release:perform fails more often than the taging/comitting steps in release:prepare. - E.g. I run release:prepare and some plugins are only activated when performRelease is set (checkstyle, rat, gpg, license-checker). As you say, that all depends on how you run your plugins. I normally -DskipTests=true into one or the othe (prepare or perform). - You may argue that I just should activate the same profiles during preparationGoals (-DperformRelease=true clean verify) and be good. - But we have multi-module builds, where tests takes several hours (a problem of it's own, I know), so teams are not willing to run tests during prepare *and* perform. If you think of the prepare as the SCM operations, and the perform as the real testing stage, then you've got a good (and I think correct) separation. I prefer to run the tests in the perform stage, as they can be re-run. That is why perform *can* be rerun; it was designed to be. - I could advise them to run the tests during prepare only, however this feels strange as the binaries are deploy are not the same. And why I don't. The binaries are different? Why? That aside, running in the perform stage means that you are truly testing the released binaries, no ifs buts or maybes. - So I advise them to skip tests during prepare (you could even set preparationGoals=clean). I do. - Then you may end with tags which never make it into production as a test broke during release:perform. So? Ignoring the fact that perform can be rerun, you're always going to have 'broken' releases. Whether due to broken code or a testing failure (valid or intermittent) or not, you're always going to have to contend with the possibilies of a broken release. I think that you're pushing too much value onto the current working definition of what a release is. A release is a release that matches a SCM tag. That's it. Whether it works or not is yet to be determined. Even *if* it reaches production, that does not meant that it works. Or should have gone to production either... - While this is no problem, when you only do release builds every other day, other teams want to deploy continuously and then you are Well, the fundamental issue here is that of expectations. 4+ hour builds and continuous deployment are pretty much mutually exclusive here. CD here is wishful thinking. Oh, in the WebSphere Process Server sense, after a 4+ hour build, the deployments themselves took 2-3 hours (absolute worst case). In my case, I forced a nightly build. The devs soon learned that things had to be done by the end of the day or else they would not be in the release. So what I want is a simpler CI/CD job definition. If I can say to Jenkins that the release command is: mvn release:prepare release:perform release:finalize Then I don't have to worry if the job is on git or svn. The finalize can take care of closing the staging repo as well as pushing changes. Perform could even delete any prior staging repos so that I'm able to get a clean run. If the build failed then I just re-run and it will start from prepare again on a clean checkout and create a new tag for the same version. (Not that I always agree with respinning a version number, but it can be handy as long as you know the old version cannot be retained (clearing out the staging repo and purging the workspace with job specific maven repo cache allows for that)) left with a lot of non-deployed tags in your SCM after a while (or you would need a procurement mechanism of tags which made it into production). You could equally have a large number of tags that DID make it into production! Again, so what? I introduced the concept of a Platform Release, which was a cherry picking of what versions of what formed a release. - PortalRelease-X.Y.Z.B - a collection of 3-5 Portal ears/wars. - WPSRelease-X.Y.Z.B - a collection of 30 odd EARS, and around 30 odd Testing EARS (Process Server) - WMBRelease-X.Y.Z.B - a collection of 40+ Message Broker BAR files. (Message Broker) etc Each of the XXXRelease projects was a zip file. Then I released the PlatformRelease projects (yes, a cascading release mechanism) that
Re: release-plugin: push changes after perform for DCVS
I'm not actually sure of what problem you're trying to solve here. On Sat, Apr 11, 2015 at 6:49 AM, Mirko Friedenhagen mfriedenha...@apache.org wrote: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. I have a real problem with the word 'probably' here. As there will always be times when that is not the case, when things fail. Sometimes on a permanent basis, sometimes a temporary failure. What appears to be the case here, is that we've come up with a proposed solution to a problem that I have no clear idea about. Can someone please elaborate? What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: release-plugin: push changes after perform for DCVS
On Sat, Apr 11, 2015 at 7:06 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Stephen, this does sound even more reasonable. release.properties is deleted at the end of perform, so the goal could only rely on information in the pom. Doesn't release:clean effectively do that? Regards Mirko -- Sent from my mobile On Apr 11, 2015 9:40 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I could see value in a release:finalize goal that is a no-op for non-DCVS but does a push changes for DCVS It would mean that you could go mvn release:prepare release:perform release:finalize in one command to close it all out On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org wrote: Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: release-plugin: push changes after perform for DCVS
I could see value in a release:finalize goal that is a no-op for non-DCVS but does a push changes for DCVS It would mean that you could go mvn release:prepare release:perform release:finalize in one command to close it all out On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org wrote: Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: release-plugin: push changes after perform for DCVS
Stephen, this does sound even more reasonable. release.properties is deleted at the end of perform, so the goal could only rely on information in the pom. Regards Mirko -- Sent from my mobile On Apr 11, 2015 9:40 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I could see value in a release:finalize goal that is a no-op for non-DCVS but does a push changes for DCVS It would mean that you could go mvn release:prepare release:perform release:finalize in one command to close it all out On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org wrote: Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: release-plugin: push changes after perform for DCVS
I think a `finalizeGoals`, defaulting to `initialize` would suffice to give people enough of a hook. You could then either implement a custom lifecycle or attach the blue-green toggle actions to a special profile and the push changes would be part of the default impl of the mojo. That would give enough of a hook while retaining simplicity. NB blue-green for most people would be promoting the staging repo. For us it would also include pushing the site live On Saturday, April 11, 2015, Robert Scholte rfscho...@apache.org wrote: I've been thinking of a finalize as well, as something which could be executed if a vote/stage has passed. But those actions differ between organizations, which would mean either introduce a lot of hooks or give an API so users can write their own finalize phases Op Sat, 11 Apr 2015 09:38:10 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: I could see value in a release:finalize goal that is a no-op for non-DCVS but does a push changes for DCVS It would mean that you could go mvn release:prepare release:perform release:finalize in one command to close it all out On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org wrote: Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Sent from my phone
Re: release-plugin: push changes after perform for DCVS
On Saturday, April 11, 2015, Hervé BOUTEMY herve.bout...@free.fr wrote: Le samedi 11 avril 2015 12:31:03 Stephen Connolly a écrit : I think a `finalizeGoals`, defaulting to `initialize` would suffice to give perhaps an autoFinalize boolean too, by default true, for people requiring the simple current 2-phase release process people enough of a hook. You could then either implement a custom lifecycle or attach the blue-green toggle actions to a special profile blue green toggle actions: what is it? In CD you often use blue-green deployment patterns. The app/site is pushed to one live environment, then when you are ready, you toggle a switch (typically either a DNS entry with a short TTL or a load balancer routing rule) and the new version is live... Then you can tear down the old version servers at your convenience (though typically they are retained as the next staging site because you'll be releasing often) thus each environment gets toggled back and forth between blue and green. and the push changes would be part of the default impl of the mojo. That would give enough of a hook while retaining simplicity. NB blue-green for most people would be promoting the staging repo. For us it would also include pushing the site live oh yeah, I didn't think about it: yes, automating site release would be great, since it's a pain at the moment! big +1 Regards, Hervé On Saturday, April 11, 2015, Robert Scholte rfscho...@apache.org javascript:; wrote: I've been thinking of a finalize as well, as something which could be executed if a vote/stage has passed. But those actions differ between organizations, which would mean either introduce a lot of hooks or give an API so users can write their own finalize phases Op Sat, 11 Apr 2015 09:38:10 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com javascript:;: I could see value in a release:finalize goal that is a no-op for non-DCVS but does a push changes for DCVS It would mean that you could go mvn release:prepare release:perform release:finalize in one command to close it all out On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org javascript:; wrote: Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org javascript:;: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
Re: release-plugin: push changes after perform for DCVS
I've been thinking of a finalize as well, as something which could be executed if a vote/stage has passed. But those actions differ between organizations, which would mean either introduce a lot of hooks or give an API so users can write their own finalize phases Op Sat, 11 Apr 2015 09:38:10 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: I could see value in a release:finalize goal that is a no-op for non-DCVS but does a push changes for DCVS It would mean that you could go mvn release:prepare release:perform release:finalize in one command to close it all out On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org wrote: Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: release-plugin: push changes after perform for DCVS
Le samedi 11 avril 2015 12:31:03 Stephen Connolly a écrit : I think a `finalizeGoals`, defaulting to `initialize` would suffice to give perhaps an autoFinalize boolean too, by default true, for people requiring the simple current 2-phase release process people enough of a hook. You could then either implement a custom lifecycle or attach the blue-green toggle actions to a special profile blue green toggle actions: what is it? and the push changes would be part of the default impl of the mojo. That would give enough of a hook while retaining simplicity. NB blue-green for most people would be promoting the staging repo. For us it would also include pushing the site live oh yeah, I didn't think about it: yes, automating site release would be great, since it's a pain at the moment! big +1 Regards, Hervé On Saturday, April 11, 2015, Robert Scholte rfscho...@apache.org wrote: I've been thinking of a finalize as well, as something which could be executed if a vote/stage has passed. But those actions differ between organizations, which would mean either introduce a lot of hooks or give an API so users can write their own finalize phases Op Sat, 11 Apr 2015 09:38:10 +0200 schreef Stephen Connolly stephen.alan.conno...@gmail.com: I could see value in a release:finalize goal that is a no-op for non-DCVS but does a push changes for DCVS It would mean that you could go mvn release:prepare release:perform release:finalize in one command to close it all out On 10 April 2015 at 22:36, Robert Scholte rfscho...@apache.org wrote: Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
release-plugin: push changes after perform for DCVS
Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: release-plugin: push changes after perform for DCVS
Hmmm, no so sure about that. The whole concept is that 'prepare' should do all the scm actions. 'perform' should only do a checkout from the tag and run 'mvn deploy'. There should be as less as possible actions after uploading the artifacts to a repository manager. Did you ever face issues with deploying the site (well, I did... it's not nice but I know the workarounds) the maven-release-plugin is already quite complex, we should try to keep the chances of a failing release as low as possible. Robert Op Fri, 10 Apr 2015 22:49:44 +0200 schreef Mirko Friedenhagen mfriedenha...@apache.org: Hello, we now have pushChanges and localCheckout in the release:prepare goal. IMO pushing commits and tags after a successful release:perform or release:stage would be a good thing then, as this will probably succeed most of the times. What do you think about something like pushChangesAfterPerform? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
