Hi tison,
On 9.01.2025 11:22, tison wrote:
I'd like to establish a consensus to explicitly allow making release
candidates publicly accessible during the voting period.
This should be an existing exercise that the source code of release
candidates is available on dist.apache.org, e.g., [1].
[1] https://dist.apache.org/repos/dist/dev/flink/flink-connector-jdbc-3.1.1-rc1/
The situation I'd like to highlight here is that, nowadays verifiers
would find it more convenient to pull the release candidate from a
central repository, like Maven Central, PyPI, crates.io, etc.
I don't know if other projects release versions like 1.0.3-rc.1 to
those repositories during the voting period, but I know a few projects
won't do that before a formal release is cut. This actually harms the
verification the release candidate could receive.
Making a release candidate version on those repositories should be the
same as publishing the source code to dist.apache.org/repos/dist/dev
with an RC tag. So, I'd establish a consensus to allow doing so
explicitly.
First of all, I share your intention of having the largest number of
users test our Release Candidates before the official release. If other
projects were able to test our candidates **before** the end of the
voting period:
* We could prevent some botched versions from ever reaching general
availability.
* The projects consuming our artifacts would be able to upgrade faster,
if our release is followed by a CVE announcement.
I would love to see a version/clone of Dependabot that can test RCs.
Personally I am +1 to allow projects to publish RCs without a vote, but
whether that is a good idea depends on the ecosystem. In Apache Logging:
* we publish the RCs of `log4net` to NuGet Gallery and we **remove**
them after the vote ends.
* we use Nexus staging repositories for the `log4j` releases, because
Maven Central does not allow the removal of artifacts. We have some GH
workflows with integration tests that accept as input the URL of the
staging repo, so we can run automatic tests on our RCs. It would be
probably easy to adapt those workflows to test RCs of our dependencies,
the only thing that is really missing right now is a way to
automatically discover that a vote has been started.
One thing to take into account, when choosing which publishing strategy
to use for RCs is reproducibility: in the Java ecosystem we want to have
reproducible artifacts, so we are not allowed to publish RCs with an
`-rc.1` suffix and remove the suffix after the vote.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
