>So your formal releases are produced by manually running the release >plugin? And if it fails, you manually do a rollback, depending on the >failure?
Yes, we manually roll it back. It's not too bad with svn, but a bit annoying I'll admit. We haven't tackled the release tools yet. >Some of our teams wish to automate the creation of a release say every >week and include all feature and bug fixes for that week in the release. >The problem of course is that the release plugin commits changes to the >trunk. If for whatever reason the formal build fails, and no person is >there to immediately investigate and do a rollback, you could have your >trunk in an bad state which is something we of course wish to avoid. When we start to converge on a release, we cut a branch for that release stream. That means that when we actually start staging releases, the devs have moved on to the next release which is another trunk/branch. So for example, we had recently done 1.3.1. At the time that occurred, we branched it off and the mainline became 1.3.2 (there is 1.4 as trunk but irrelevant for now). We staged the 1.3.1 releases off of that rolling back as needed. Eventually 1.3.1 became idle until we did a quick patch for 1.3.1.1. As we got closer to 1.3.2, we spun that off to a branch and the mainline became 1.3.3 etc. Typically the devs work on the mainline and merge back to the release branch once it's cut, but it could go either way. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
