Good practice too. I'm using it also at work and we are doing our releases on dedicated branches.
--------- Arnaud Le 14 sept. 2013 à 19:30, Fred Cooke <[email protected]> a écrit : > You're in Git now. You don't *have* to push your tag and release commits up > to the public world until AFTER you've checked they're OK. Or by failed > release do you mean voted down? They could live on branches until set in > stone, then merge --ff-only into master at that point, if so. > > > On Sat, Sep 14, 2013 at 7:24 PM, Jason van Zyl <[email protected]> wrote: > >> When a release fails like this it is annoying to have to rev back the >> version of the POM. I'm not sure who flipped the versions in the POM and >> while it's a little more visible to see what you're moving toward I prefer >> the pattern of: >> >> 3.1-SNAPSHOT --> 3.1.1 --> 3.1-SNAPSHOT --> 3.1.2 --> 3.1-SNAPSHOT >> >> I know this may not be obvious to the casual observer as they may think >> 3.1 is next, but I'm personally fine with that. >> >> Especially after a failed release because then I don't have to go change >> all the POMs (whether rolling back manually, using the release rollback, >> the version:set command, or whatever else). It's much easier to just fix >> what's necessary and carry on. >> >> Unless anyone objects I would like to go back this pattern, what I >> previously had, because it's far easier to manage. Ideally it might be nice >> if all the tools understood 3.1.z-SNAPSHOT but they don't an in lieu of >> that I would prefer not to diddle POMs after a failed release. >> >> Thanks, >> >> Jason >> >> ---------------------------------------------------------- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> --------------------------------------------------------- >> >> >> >> >> >> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
