@Jarek:
> but how PMCS turn that into practice - should be up to them.
Of course. As stated in the the first mail, I'd "establish a consensus
to explicitly allow making release candidates publicly accessible
during the voting period."
It's to "allow" or hint PMCs that they can do so, because, as per
other discussions recently, the 72 hours "requirements" would give a
wrong assumption that it's a MUST and even release candidates can only
stay in dist.apache.org/repos/dist/dev for devs who are able to verify
everything from the source code.
And different languages has their own idiom, like Go can leverage a
Git tag 1.0.3-rc.1, and Rust's cargo can set apache-foo = { git =
"<repo-url>", tag = "1.0.3-rc.1" }. We don't limit the implementation,
just that PMCs _can_ "publish" their RC to central repositories.
@Gary:
> Is this an opt-in or opt-out policy?
It's an opt-in, IMO, suggestion. I'm sorry that the title may read
like a policy, but I actually wrote it to seek a consensus to allow
doing this, not a requirement.
> We wouldn't want to do that for CVE fixed right?
Yes.
@Piotr:
Thanks for your feedback and sharing on how to do with Java/Maven
project. That looks good.
Best,
tison.
Gary Gregory <garydgreg...@gmail.com> 于2025年1月9日周四 20:43写道：
>
> Is this an opt-in or opt-out policy? We wouldn't want to do that for CVE
> fixed right?
>
> Gaty
>
> On Thu, Jan 9, 2025, 07:07 Jarek Potiuk <ja...@potiuk.com> wrote:
>
> > Sorry " should be *not *to encourage the projects to make it easy for
> > anyone to install and test the release" -> "should be to encourage the
> > projects to make it easy for anyone to install and test the release"
> >
> > On Thu, Jan 9, 2025 at 1:06 PM Jarek Potiuk <ja...@potiuk.com> wrote:
> >
> > > Just a small thing to add - while we are releasing RCs, I think the right
> > > approach should be not to encourage the projects to make it easy for
> > anyone
> > > to install and test the release - which does not automatically mean to
> > > publish RC in the same way the final candidate is published.
> > > The key here is to let the users know that there is a candidate and
> > > encourage them to test it. I think it has more nuances than publishing to
> > > Maven/ PyPI etc. - and PMCs should choose their own ways and encourage
> > > their "dev community" (not end users mind you - those users might be
> > > misled into thinking this is the final release!) to test it.
> > >
> > > There are many ways how this can be done:
> > >
> > > * Airflow is indeed publishing RC candidates in PyPI (PyPI has a great
> > > distinction between pre-release and final candidates and users cannot
> > > mistake them for final versions, they need to explicitly install RC
> > > candidates) and we invite contributors to test the releases via GitHub
> > > issue (automated) where we mark the involved contributors: example here -
> > > https://github.com/apache/airflow/issues/45148 - we usually have at
> > > least 60% "success" rate - i.e. more than half of the users involved are
> > > willing to take the RCs for a spin, install it and test it (and confirm
> > it
> > > works or report issues). This sustainably works for 3-4 years now.
> > >
> > > * However, quite recently in the Python ecosystem at least where the
> > > Python Community standardised packaging and build backend/front-end
> > > approach - it is a very common practice to use GitHub branches to install
> > > the software. There is a way to do it it in a standard way and more often
> > > than not when we find and report (or comment) an issue in a dependent
> > > library, they create a PR and ask everyone to test it from the branch -
> > an
> > > example of it recently where we found a problem in Pygments and they
> > > created a PR fixing it - issue here
> > > https://github.com/pygments/pygments/issues/2834, PR in Airflow testing
> > > the change in PR here:
> > https://github.com/apache/airflow/pull/45416/files
> > > (basically replacing "pygments>=2.0.1,!=2.19.0" with "pygments @ git+
> > >
> > https://github.com/pygments/pygments.git@a9858663ed85219ed7475f5877b22b9cb49f660f
> > ".
> > > This is a very efficient way of testing - because you can test the fix
> > not
> > > when all the burden of release preparation and rc candidate preparation
> > is
> > > done, but way before, even way before the PR with fix is merged. This is
> > > something we are actually going to encourage more - currently our 90+
> > > providers in our monorepo are not installable via GIT URL, but we are
> > > implementing restructuring to make it possible - so that you can install
> > > any of our packages directly from our monorepo github repo - specifying
> > the
> > > package you want to install, URL and commit-ish git reference.
> > >
> > > So if we want to add something about policies/best practices - we should
> > > rather describe the "INTENTION" to have RC (or even PR!) candidates being
> > > easily available to install and test, but how PMCS turn that into
> > practice
> > > - should be up to them.
> > >
> > > J.
> > >
> > >
> > >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org
