On Fri, Apr 15, 2016 at 10:43 AM, sebb <seb...@gmail.com> wrote: > On 15 April 2016 at 17:59, James Carman <ja...@carmanconsulting.com> > wrote: > > On Fri, Apr 15, 2016 at 12:57 PM James Carman < > ja...@carmanconsulting.com> > > wrote: > > > >> On Fri, Apr 15, 2016 at 12:53 PM sebb <seb...@gmail.com> wrote: > >> > >>> That is effectively what the final release tag is. > >>> We vote on the RC tag, and create the release tag from the successful > RC > >>> tag. > >>> > >>> > >> Yep, we're not far off. What I'm proposing is that we try to use the > >> Maven Release Plugin to create our releases and push them to a staging > >> repository in Nexus for a vote. If the vote fails, drop the staging > repo. > >> If we truly want immutable tags, then maybe we just create the release > with > >> a tag of "foo-1.2.3-rc1" (as someone has pointed out, the release plugin > >> can do) and then once (or if) it passes, copy it to > "releases/foo-1.2.3". > >> I must admit, I haven't RM'd a release in a while, mainly because I > found > >> it to be extremely painful. Anything we can do to make that process > easier > >> could only help us release more often. Obviously we can't sacrifice > >> traceability of the code, but I think we can find a workable solution. > >> > > > > Again, we can just stick to the regular process > > "the regular process" is what is under discussion. > > In my experience the Commons "regular process" means an immutable > release tag created from the RC tag. > > > and just "burn" version > > numbers for votes that don't pass. Versions != releases. >
Burning versions would be a sign of a failure in our release process IMO. Maven does this release burning still today. I am against it. A tag should be created for all RCs to easily track what we vote on. Granted that voting on a SVN revision or Git hash should provide the same info. Gary > > Skipping versions has consequences. > For example @since markers, JIRA Fix versions etc. > It's confusing if these relate to versions that were never released; > the alternative is to fix them. More work. > > So it would be better not to abandon versions. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
