Hello Incubator community,
This is a call for a vote to release Apache Pekko(incubating) version 1.0.0-RC3.
The Pekko community vote result:
https://lists.apache.org/thread/dwfc5h4jdvwld4z6fhzm87x1fyrv3gw4
The Pekko community vote thread:
https://lists.apache.org/thread/gkn1b3mddgo82doj4c0f38o
> n this way, the automation would be triggered
>at the formal tag pushed
>after the vote passed.
Correct me if I am wrong, however, if a release vote includes only sources,
then creating and publishing binaries separately would violate the release
policy.
Creating the binaries and publishing the
Thank Chris for your feedback!
You're right and an alternative is to postpone the binaries release until
the vote passed, while the vote still focuses on sources and any users can
build their binaries to verify.
In this way, the automation would be triggered at the formal tag pushed
after the vot
Hi Tison,
well with most projects that use Maven as distribution chanel, the RC artifacts
are in a staging repo in Nexus. If the vote fails, then this repo is dropped
and nothing is released to the outside world. If it passes, we click on
"release" and the artifacts are released to the outside
> if It's ok to still publish RCs without a vote
I think we vote for RCs so we always provide RCs without a vote. At least
it's what I'm experiencing among Flink, Pulsar, and so on.
Best,
tison.
Christofer Dutz 于2023年7月4日周二 19:52写道：
> Hi Tison,
>
> Well, it definitely is better than without,
Hi Tison,
Well, it definitely is better than without, however I am still not sure, if
It's ok to still publish RCs without a vote.
Currently there's quite a bit of discussion on the matter of releasing binary
artifacts, so I would call this part a bit in flux right now.
But hopefully someone el
Hi Chris.
1. Is -rc suffix a satisfied alternative to you?
2. This can be part of binary release topics. I read our policy to release
sources only so I don't push an alert for doing so. But I do assume -rc
suffix could be an improvement before the podling getting graduated.
Best,
tison.
Christo
Hi all,
I don't think this procedure is ok according to our policies.
Simply not listing a release on the project page will not help anyone using
this as a dependency.
At least, every time I update a dependency, I never check the projects page, if
this is even a released version.
Chris
Am
Here are four workflows to release Rust, Node.js, Python and Ruby libraries
to their conventional repository.
1. Rust Cargo -
https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml
2. Python PyPi -
https://github.com/apache/incubator
Hi all,
in PLC4X we have a maven-plugin that we use to generate code for PLC4X itself.
In order to avoid super-messy releases, we have that plugin and similar
build-tools in a separate repo.
This is released using the normal release process.
It does help however to cut the build-tools to work
Hello! I think, in principle, the vote is the right thing to do. Is
this artifact likely to change frequently? My experience with sbt
plugins is that they are usually pretty tightly integrated with the
projects that depend on them. If this is the case you might want to
have it released at the sam
Hi Tison,
Would it be possible to provide us with links to documentation about
how you deploy your binary artifacts and how they can be revoked if a
vote fails?
I think this is useful for IPMC members when they are reviewing your
release candidates. It's nice to review the binaries as well as the
Hi Incubator PMC,
The vote to release Apache OpenDAL(incubating) 0.38.0-rc1 has passed with
3 +1 binding and 2 +1 non-binding votes, no +0 or -1 votes.
Binding votes：
- PJ Fanning
- tison
- Willem Jiang
Non-Binding votes:
- Xuanwo
- Kent Yao
Vote thread: https://lists.apache.org/thread/zr
+1 (nonbinding), I have checked:
[✓] The checksums and signatures are validated
[✓] The LICENSE and NOTICE are fine
[✓] DISCLAIMER is present
[✓] No binary files in the source release
[✓] incubating in the name
[✓] Successfully built the binary from the source on my Mac
Kent Yao
On 2023/07/04 09
Thanks Claude but I am not familiar with the terminology of 'Petri
route'. Would you be able to provide more detail?
So far based on the existing feedback - the aim is to just set up an
RC for this component and go through the regular voting process on it.
A Pekko community discussion and vote fol
On 2023-07-04 11:44, Claude Warren wrote:
You could try the Petri route if the devs are ASF members.
Regardless of the route chosen, for an official release you will always
need to adhere to the standard release process (72+ hours, min 3x+1,
more +1s than -1s, must be ALv2, etc etc). I don't
You could try the Petri route if the devs are ASF members.
On Mon, Jul 3, 2023 at 5:12 PM Sheng Wu wrote:
> Hi
>
> If we want that jar under asf package on maven central, yes, a new version
> is required a vote on dev first, then incubator.
> Meanwhile, if we have all mentors(ipmc members as wel
+1. Here is what I checked:
- The checksums and signatures are validated.
- The LICENSE and NOTICE files look good to me.
- There is a DISCLAIMER file about incubating.
- No binary files in the source release.
Willem Jiang
Twitter: willemjiang
Weibo: 姜宁willem
On Wed, Jun 28, 2023 at 10:31 PM Ch
18 matches
Mail list logo
