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. 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
