On Tue, Mar 31, 2015 at 7:44 AM, Branko Čibej <br...@apache.org> wrote:
> On 31.03.2015 16:00, Stian Soiland-Reyes wrote:
>> 8) It would be good to avoid all those "RC RCs" as it's confusing to
>> have multiple levels of release candidates - in Apache, a Release
>> Candidate is this particular thing you are asking us to vote over.
>> (this might have been pointed out earlier). A pre-release can be
>> called anything else, like alpha, golden master, etc.
>> https://www.apache.org/dev/release.html#what
>
> We've been through this and I disagree. Do not confuse release process
> with release naming. That page conflates the two, which makes it just a
> bit broken IMO. There are no rules for release naming "in Apache".

It would be more apparent that the podling has their release process under
control if the release-process-candidates being iterated on were clearly
differentiated using unambiguous directory names, Git tag names, etc.

For example, the last vote could have been on...

  http://people.apache.org/~dsetrakyan/ignite-1.0.0-RC3-rc2
  GIT tag release-1.0.0-RC3-rc2

... and this vote could have been on:

  http://people.apache.org/~dsetrakyan/ignite-1.0.0-rc0
  GIT tag release-1.0.0-rc0

That's still a little hard to follow, but at least it distinguishes different
release-process-candidates from each other.

I understand the rationales as to why Ignite might need an official release
called "1.0.0-RC3", but is there nothing that the podling can do about the
problem of voting on several different things all with the same name?  Is
the Ignite community clear on why that might cause problems?

During the PPMC vote thread for the last release, I see this exchange:

    > > GIT tag: release-1.0.0-RC3 (I deleted the old RC3 tag and created the
    > > new one)
    >
    > For the future, I recommend not moving a tag; instead, if a release
    > package is bad, just create the next highest numbered package; in this
    > case, it'd be RC4 (or more likely RC5, since this is the second
    > resubmission of the "same" package). Doing it this way avoids possible
    > misunderstandings about what is being proposed for release.

    I agree. Will do it next time. My hope though is to get a +1 for this one,
    so I won't have to :)

Yet here we are voting on something ambiguous again -- and predictably,
another person has gotten confused.  It doesn't block this VOTE, but I hope
that Ignite follows through and does things differently in the future.

Marvin Humphrey

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Reply via email to