Thank you, Jacek, Sean, and Hyukjin.
The release is a human-driven process. Everyone can make mistakes.
For example, I released Apache Spark 2.2.3 with a missing pandoc, but we
didn't touch it because it's a community-blessed official version.
https://pypi.org/project/pyspark/2.2.3/
For this incident, given the situation, I'm +1 for `Skipping 3.1.0 and
starting 3.1.1 RC1` instead of making it official.
It's because
1. The vote is important in the Apache project management process.
The existing 3.1.0 artifacts in Maven Central are not a
community-blessed version.
2. Since this is the first incident, we had better build a rule to handle
this kind of accident.
If we approve `3.1.0` because it's published accidently, it could be a
bad practice.
In the worst case, a release manager can publish Spark 10.1.1
accidently in the future without votes.
BTW, thank you, Hyukjin, for your all efforts to prepare 3.1.0 as a release
manager.
We know that you devote lots of your time to make it happen.
Bests,
Dongjoon.
On Wed, Jan 6, 2021 at 1:07 PM Hyukjin Kwon <[email protected]> wrote:
> Yes, it was my mistake. I faced the same issue as INFRA-20651
> <https://issues.apache.org/jira/browse/INFRA-20651>, and it is worse in
> my case because I misunderstood that RC and releases are separately
> released out.
> Right after this, I filed an INFRA JIRA to revert this at INFRA-21266
> <https://issues.apache.org/jira/browse/INFRA-21266>. We can wait and see
> how it goes.
>
> Though, I know it’s impossible to remove by right. It is possible to
> overwrite but it will affect people who already have it in their cache.
> I am thinkthing two options:
>
> - Skip 3.1.0 and release 3.1.1 right away since the release isn’t
> officially out to the main Apache repo/mirrors but only one of the
> downstream channels. We can just say that there was something wrong during
> the 3.1.0 release so it became 3.1.1 right away.
>
>
> - Release 3.1.0 out, of course, based on the vote results here. We
> could release 3.1.1 fast that exceptionally allows a bit of breaking
> changes with properly documenting it in a release note and migration guide.
>
> I would appreciate it if I could hear other people' opinions.
>
> Thanks.
>
>
>
>
