On Wed, Jan 13, 2016 at 12:18 PM, Justin Erenkrantz
<[email protected]> wrote:
> Even if the release fails the vote, you shouldn't be reusing that
> version again.
And that's where the current suggested mode becomes super confusing
*unless* we all agree not to use RC designation.
Here's a scenario that is very likely to happen:
1. An actual release with a version string 1.0.0-incubating.RC1 is
put up for a vote. Lets call it artifact #1
2. The vote fails.
3. You create artifact #2 with exactly the same version string
1.0.0-incubating.RC1 to take care of the issues that made
the vote fail
How do you avoid confusion between referring to #1 vs. #2 ? In 99%
of asf projects you'd call #1 an RC1 and #2 RC2. But then of course
you're talking 1.0.0-incubating.RC1 RC2 -- if that's not confusing I don't
know what is. So that's no good at all.
Alternatively (and that's how Apache Subversion does it as community,
not as a source code management tool) you could skip #s if the vote
fails. So once #2 happens you will produce 1.0.0-incubating.RC2 without
every using 1.0.0-incubating.RC1 ever again. I suppose that this could
work, but lets be absolutely clear about the steps then.
IOW, if the following statement captures what Geode community *really*
wants to do -- I have nothing against it (aside from the fact that you'd
be different from 99% of projects I know in ASF).
Here's the statement: every single time a vote fails on MX or RCX artifact
you proceed to vote on M(X+1) or RC(X+1) without *ever* re-using
MX or RCX version IDs. IN ADDITION, when you're ready to produce
.RELEASE release you simply re-use the last RCZ version and call
it a RELEASE. IOW, the vote on a RELEASE never really happens. The
vote always happens on RCZ and then the community declares it to
be a release.
Phew. That was a pretty convoluted statement, but if you really want
the above to be your release policy -- sure.
Thanks,
Roman.
