For comparable use case I use the release:stage goal (in place of release:perform) to create the release but not remove the "rolback" files. I can then create a 1.0 release to get tested, and return to 1.0-SNAPSHOT if some issues are found. I just have to rename the tag from 1.0 to 1.0-rcX (or delete it).
Nicolas 2008/7/17 Stephen Duncan Jr <[EMAIL PROTECTED]>: > On Thu, Jul 17, 2008 at 8:46 AM, Stephen Duncan Jr < > [EMAIL PROTECTED]> > wrote: > > > I want to use the release plugin to make testing releases, without > > interrupting ongoing development. So, for example I want to take a > project > > that is at 1.0-SNAPSHOT, and has dependencies that are at 1.0-SNAPSHOT. > I > > want to make a release for 1.0-beta-1, with the dependencies at > 1.0-beta-1 > > (assume I've already made those releases). And then I want trunk to be > back > > at 1.0-SNAPSHOT for the version and dependencies. > > > > Right now, that almost works, except the release plugin won't accept > > 1.0-SNAPSHOT as the "new development version" for the dependencies. > Should > > I enter that as a feature request/bug? Is there a better practice I > should > > follow? > > > > -- > > Stephen Duncan Jr > > www.stephenduncanjr.com > > > > Oh, and also it will try to set the new version of the dependencies to > release, but it doesn't tell you that it goes to "1.0" instead of > "1.0-beta-1". > > -- > Stephen Duncan Jr > www.stephenduncanjr.com >
