Release builds and continuous integration
I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match the code tagged for that release in source control. Any ideas on how to address this problem? One approach would be to have some plugin on the continuous build machine that checks the projects before starting the build (but after the latest code is obtained from SCM) to see if any projects have a release (non-snapshot) currentVersion value. If so, this plugin would use the version element for this version to make sure that the code that will be built matches the tag for this release. Then it lets the build go on. Would this be hard in Maven 2? Even better would be to have a plugin that, once the release build is finished and deployed, would change the currentVersion to the next snapshot version. What do you think? Has anyone else had to deal with this risks? Is there a better approach to solve these problems that I'm not seeing? Thanks, ..David..
RE: Release builds and continuous integration
I really dislike your suggestion for item 1, since that implies that if I discover a problem with the release build and have to rebuild it, I have to remember to manually remove the release build from the repository first. -Original Message- From: David Jackman [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 10:54 To: Maven Users List Subject: Release builds and continuous integration I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match the code tagged for that release in source control. Any ideas on how to address this problem? One approach would be to have some plugin on the continuous build machine that checks the projects before starting the build (but after the latest code is obtained from SCM) to see if any projects have a release (non-snapshot) currentVersion value. If so, this plugin would use the version element for this version to make sure that the code that will be built matches the tag for this release. Then it lets the build go on. Would this be hard in Maven 2? Even better would be to have a plugin that, once the release build is finished and deployed, would change the currentVersion to the next snapshot version. What do you think? Has anyone else had to deal with this risks? Is there a better approach to solve these problems that I'm not seeing? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release builds and continuous integration
Consider that this is outside of the build tool. I suggest branching to a release codeline for releasing from, when the product is ready. Your release process sounds formal enough for this (it is usually easy to be formal enough). You can also then take care of #2 by having it monitor the release codeline too. Each codeline must have only one purpose, and at the time of your release, you are overloading that codeline with two purposes - ongoing development and releasing. Hopefully you will find, as others do, this approach simplifies the release prep process. Quoting David Jackman [EMAIL PROTECTED]: I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match the code tagged for that release in source control. Any ideas on how to address this problem? One approach would be to have some plugin on the continuous build machine that checks the projects before starting the build (but after the latest code is obtained from SCM) to see if any projects have a release (non-snapshot) currentVersion value. If so, this plugin would use the version element for this version to make sure that the code that will be built matches the tag for this release. Then it lets the build go on. Would this be hard in Maven 2? Even better would be to have a plugin that, once the release build is finished and deployed, would change the currentVersion to the next snapshot version. What do you think? Has anyone else had to deal with this risks? Is there a better approach to solve these problems that I'm not seeing? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release builds and continuous integration
My understanding is that if you are making changes to official release you really should increment the version (and tag it in CVS/SVN). Vitaliy On 10/3/05, Allison, Bob [EMAIL PROTECTED] wrote: I really dislike your suggestion for item 1, since that implies that if I discover a problem with the release build and have to rebuild it, I have to remember to manually remove the release build from the repository first. -Original Message- From: David Jackman [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 10:54 To: Maven Users List Subject: Release builds and continuous integration I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match the code tagged for that release in source control. Any ideas on how to address this problem? One approach would be to have some plugin on the continuous build machine that checks the projects before starting the build (but after the latest code is obtained from SCM) to see if any projects have a release (non-snapshot) currentVersion value. If so, this plugin would use the version element for this version to make sure that the code that will be built matches the tag for this release. Then it lets the build go on. Would this be hard in Maven 2? Even better would be to have a plugin that, once the release build is finished and deployed, would change the currentVersion to the next snapshot version. What do you think? Has anyone else had to deal with this risks? Is there a better approach to solve these problems that I'm not seeing? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release builds and continuous integration
Unless, of course, the problem wasn't the code but that it was packaged incorrectly. In this case, I am only correcting the packaging, not the release. -Original Message- From: Vitaliy Geraymovych [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 11:28 To: Maven Users List Subject: Re: Release builds and continuous integration My understanding is that if you are making changes to official release you really should increment the version (and tag it in CVS/SVN). Vitaliy On 10/3/05, Allison, Bob [EMAIL PROTECTED] wrote: I really dislike your suggestion for item 1, since that implies that if I discover a problem with the release build and have to rebuild it, I have to remember to manually remove the release build from the repository first. -Original Message- From: David Jackman [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 10:54 To: Maven Users List Subject: Release builds and continuous integration I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match the code tagged for that release in source control. Any ideas on how to address this problem? One approach would be to have some plugin on the continuous build machine that checks the projects before starting the build (but after the latest code is obtained from SCM) to see if any projects have a release (non-snapshot) currentVersion value. If so, this plugin would use the version element for this version to make sure that the code that will be built matches the tag for this release. Then it lets the build go on. Would this be hard in Maven 2? Even better would be to have a plugin that, once the release build is finished and deployed, would change the currentVersion to the next snapshot version. What do you think? Has anyone else had to deal with this risks? Is there a better approach to solve these problems that I'm not seeing? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release builds and continuous integration
That's correct (because if someone has already downloaded the bad release they'll never get the good one). The need to replace an official release build should be happening so infrequently that having to manually clear it out before building is not an undue burden. It's definitely worth that to prevent someone from accidentally replacing the release build. ..David.. -Original Message- From: Vitaliy Geraymovych [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 9:28 AM To: Maven Users List Subject: Re: Release builds and continuous integration My understanding is that if you are making changes to official release you really should increment the version (and tag it in CVS/SVN). Vitaliy On 10/3/05, Allison, Bob [EMAIL PROTECTED] wrote: I really dislike your suggestion for item 1, since that implies that if I discover a problem with the release build and have to rebuild it, I have to remember to manually remove the release build from the repository first. -Original Message- From: David Jackman [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 10:54 To: Maven Users List Subject: Release builds and continuous integration I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match the code tagged for that release in source control. Any ideas on how to address this problem? One approach would be to have some plugin on the continuous build machine that checks the projects before starting the build (but after the latest code is obtained from SCM) to see if any projects have a release (non-snapshot) currentVersion value. If so, this plugin would use the version element for this version to make sure that the code that will be built matches the tag for this release. Then it lets the build go on. Would this be hard in Maven 2? Even better would be to have a plugin that, once the release build is finished and deployed, would change the currentVersion to the next snapshot version. What do you think? Has anyone else had to deal with this risks? Is there a better approach to solve these problems that I'm not seeing? Thanks, ..David.. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED
RE: Release builds and continuous integration
The release process is formal enough, but I really don't want to create branches for every release. The tagged code should be enough, allowing branching only when patches need to be made for previous releases. Creating a branch for the official release also makes it extremely tedious for our goal of having the build machine do the official build. Once the branch is created, we'd have to create a new project to build the branch, and it would only get built once. I don't see the codeline having more than one purpose at release time. At certain points in the project's lifetime it's released for whatever reason. If there's ongoing development at the time, that's not a huge problem (there isn't ongoing development for the major releases so these can be more closely scrutinized). We just want to make sure that the tagged code matches the code that actually built the release artifact. ..David.. -Original Message- From: Jeff Jensen [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 9:27 AM To: Maven Users List Cc: Maven Users List Subject: Re: Release builds and continuous integration Consider that this is outside of the build tool. I suggest branching to a release codeline for releasing from, when the product is ready. Your release process sounds formal enough for this (it is usually easy to be formal enough). You can also then take care of #2 by having it monitor the release codeline too. Each codeline must have only one purpose, and at the time of your release, you are overloading that codeline with two purposes - ongoing development and releasing. Hopefully you will find, as others do, this approach simplifies the release prep process. Quoting David Jackman [EMAIL PROTECTED]: I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match the code tagged for that release in source control. Any ideas on how to address this problem? One approach would be to have some plugin on the continuous build machine that checks the projects before starting the build (but after the latest code is obtained from SCM) to see if any projects have a release (non-snapshot) currentVersion value. If so, this plugin would use the version element for this version to make sure that the code that will be built matches the tag for this release. Then it lets the build go on. Would this be hard in Maven 2? Even better would be to have a plugin that, once
RE: Release builds and continuous integration
Sorry, I wasn't clear... Don't create a new branch for _each_ release (you are very correct that that would be very tedious and completely silly!). Create them only for significant releases, e.g. release 2.0, and merge into it at each release time - reuse it for 2.0.1, and on. Then you would only setup one time the significant release on the build machine (the release build), and the CI monitors that codeline and automatically builds when detecting the changes (merges). Anyway, seems like you have a different solution in progress... Quoting David Jackman [EMAIL PROTECTED]: The release process is formal enough, but I really don't want to create branches for every release. The tagged code should be enough, allowing branching only when patches need to be made for previous releases. Creating a branch for the official release also makes it extremely tedious for our goal of having the build machine do the official build. Once the branch is created, we'd have to create a new project to build the branch, and it would only get built once. I don't see the codeline having more than one purpose at release time. At certain points in the project's lifetime it's released for whatever reason. If there's ongoing development at the time, that's not a huge problem (there isn't ongoing development for the major releases so these can be more closely scrutinized). We just want to make sure that the tagged code matches the code that actually built the release artifact. ..David.. -Original Message- From: Jeff Jensen [mailto:[EMAIL PROTECTED] Sent: Monday, October 03, 2005 9:27 AM To: Maven Users List Cc: Maven Users List Subject: Re: Release builds and continuous integration Consider that this is outside of the build tool. I suggest branching to a release codeline for releasing from, when the product is ready. Your release process sounds formal enough for this (it is usually easy to be formal enough). You can also then take care of #2 by having it monitor the release codeline too. Each codeline must have only one purpose, and at the time of your release, you are overloading that codeline with two purposes - ongoing development and releasing. Hopefully you will find, as others do, this approach simplifies the release prep process. Quoting David Jackman [EMAIL PROTECTED]: I've just started to get my hands wet with Maven 2, and I must say I like what I'm seeing. Just about every headache we currently have with Maven 1 is addressed to some extent by Maven 2. One problem we were having around Maven 1 that I'm not too sure about for the future is the issue of official release (non-snapshot) builds and continuous build tools (like CruiseControl). When releasing a Maven project, the goal is to have as much confidence as possible (a guarantee, hopefully) that the release build in the Maven repository exactly matches the code that was tagged in source control for that project. The following is a list of potential risks we have in our current Maven 1 process that I'm hoping Maven 2 can mitigate. Can anyone respond to these? 1. In Maven 1, we use the scm:prepare-release goal to start the release process. When it works (see the issues I've logged about it), this goal changes the currentVersion to the release version, tags the code in source control for the release, and adds a version element indicating the release version and its corresponding SCM tag. Sometimes, the developer doing the release will want to build deploy the official release build himself to be sure it matches the tagged code. When the release build is complete, he will (should) change the currentVersion to the next snapshot version. However, since we use a continuous build tool, there is a risk that between the time the developer deploys the release build and checks in the project.xml with the next snapshot version, the automated build will do its own build using the release version and deploy over the top of the official release build. There are steps the developer can take to mitigate this, but it would be better if Maven helped out more. For this scenario, the easiest solution would be for Maven to fail the deploy for a release (non-snapshot) version if there is already an artifact in the destination repository of the same name. Is this possible? 2. Ideally, we'd prefer that the build machine (running the continuous build tool) do the official release builds because it's more of a controlled build environment. However, there are two risks here. First is that the build tool will do more than one build of the release version (before the currentVersion is changed to the next snapshot version). The solution in the previous paragraph would help here as well. The second risk is that someone else will check in a code change before the build tool does the official release build, so the release artifact does not match
