Hi, RC's are not official releases. RC's are for vendors to make sure the "almost release" works for their technology. The vote of a vendor is not a binding vote. The RC process is a mutual courtesy to make sure the imminent release will be solid.
Once we feel that the vendors are good, we push out the release for [VOTE]. This is a much more involved process that requires a lot more effort than an RC and the only binding votes are from the TinkerPop PMC. However, I urge vendors to vote as its a useful courtesy on their part to do so. Next, we can't just tag the RC as the last release given the updates to CHANGELOG, pom.xmls, binary creation, and checksums. If people have a problem with the [VOTE] release, then the PMC can vote it down and we can rectify it for re-vote. Marko. http://markorodriguez.com On Jun 29, 2015, at 4:22 PM, Matt Frantz <[email protected]> wrote: > I would suggest that we adopt the convention of converting the final RC to > an official release by tagging the same commit that the final RC tag points > to. That is, when we vote on something, we should be voting on an > RC-tagged commit. If the vote passes, we would apply the tag to that > commit and not to wherever master happens to be. Does that sound > reasonable? Maybe this was the plan all along, but we were being a bit > more relaxed about the milestone release process, so I thought I'd confirm.
