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 world.
And just because some projects do something in a certain way, doesn't always imply that this is the right way to do things. I personally have come across several Apache projects, that are not doing things according to Apache policies and that need to change some parts of what they are doing. But as I mentioned, currently we're internally discussing how to deal with binary releases for various reasons ... because till now officially we only have source releases and convenience binaries. Chris Am 04.07.23, 13:55 schrieb "tison" <wander4...@gmail.com <mailto:wander4...@gmail.com>>: > 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 <christofer.d...@c-ware.de <mailto:christofer.d...@c-ware.de>> 于2023年7月4日周二 19:52写道： > 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 else will be able to provide more information on > this. > > Chris > > > > Am 04.07.23, 13:48 schrieb "tison" <wander4...@gmail.com > <mailto:wander4...@gmail.com> <mailto: > wander4...@gmail.com <mailto:wander4...@gmail.com>>>: > > > 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. > > > > > Christofer Dutz <christofer.d...@c-ware.de <mailto:christofer.d...@c-ware.de> > <mailto: > christofer.d...@c-ware.de <mailto:christofer.d...@c-ware.de>>> 于2023年7月4日周二 > 19:45写道： > > > > 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 04.07.23, 13:37 schrieb "tison" <wander4...@gmail.com > > <mailto:wander4...@gmail.com> <mailto: > wander4...@gmail.com <mailto:wander4...@gmail.com>> <mailto: > > wander4...@gmail.com <mailto:wander4...@gmail.com> > > <mailto:wander4...@gmail.com <mailto:wander4...@gmail.com>>>>: > > > > > > 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 > > <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml> > < > https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml > > <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml> > > > > < > > > https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml > > <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml> > < > https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml > > <https://github.com/apache/incubator-opendal/blob/975c2dde0098ba2c5014bf236e90b54f723f06b2/.github/workflows/publish.yml> > > > > > > > 2. Python PyPi - > > > > > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml> > < > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml> > > > > < > > > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml> > < > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_python.yml> > > > > > > > 3. Ruby Gems - > > > > > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml> > < > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml> > > > > < > > > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml> > < > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_ruby.yml> > > > > > > > 4. Node.js npm - > > > > > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml> > < > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml> > > > > < > > > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml> > < > https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml > > <https://github.com/apache/incubator-opendal/blob/main/.github/workflows/bindings_nodejs.yml> > > > > > > > > > > > All of them, different from the Apache Maven Nexus repository, are > > maintained by third-party platforms. So we request a token and share it > > among the Podling PMC via 1Password (a free team provision provided by > the > > team[1]). > > > > > > > revoked > > > > > > For the source releases, if the vote failed, it won't be copied to the > > release svn directory. > > > > > > For the binary releases, although all of these platforms should support > -rc > > in version tag, we release an X.Y.Z for each candidate and leave it there > > if vote failed. The version won't be listed at the official page[2]. > > > > > > I ever advice the PPMC that using a -rc suffix would be better but they > use > > this way now for convenient development. As you can see, the version > number > > is 0.X so users should already use it at their risk. If it's requested, I > > believe the PPMC would be glad to add a notice for which ones are Apache > > voted releases or use a different version tag strategy to distinguish > that. > > There should not be any blocker technically. > > > > > > OpenDAL has a release document[3] that you can refer to and do not > hesitate > > to open an issue if you find anything is unclear or unexpected. > > > > > > Best, > > tison. > > > > > > [1] https://github.com/1Password/1password-teams-open-source/pull/742 > > <https://github.com/1Password/1password-teams-open-source/pull/742> < > https://github.com/1Password/1password-teams-open-source/pull/742> > <https://github.com/1Password/1password-teams-open-source/pull/742>> < > > https://github.com/1Password/1password-teams-open-source/pull/742> > > <https://github.com/1Password/1password-teams-open-source/pull/742>> < > https://github.com/1Password/1password-teams-open-source/pull/742>> > <https://github.com/1Password/1password-teams-open-source/pull/742&gt;>> > > [2] https://opendal.apache.org/download > > <https://opendal.apache.org/download> < > https://opendal.apache.org/download> > <https://opendal.apache.org/download>> < > > https://opendal.apache.org/download> > > <https://opendal.apache.org/download>> < > https://opendal.apache.org/download>> > <https://opendal.apache.org/download&gt;>> > > [3] https://opendal.apache.org/docs/contributing/release > > <https://opendal.apache.org/docs/contributing/release> < > https://opendal.apache.org/docs/contributing/release> > <https://opendal.apache.org/docs/contributing/release>> < > > https://opendal.apache.org/docs/contributing/release> > > <https://opendal.apache.org/docs/contributing/release>> < > https://opendal.apache.org/docs/contributing/release>> > <https://opendal.apache.org/docs/contributing/release&gt;>> > > > > > > > > > > > > > > PJ Fanning <fannin...@gmail.com <mailto:fannin...@gmail.com> > > <mailto:fannin...@gmail.com <mailto:fannin...@gmail.com>> <mailto: > fannin...@gmail.com <mailto:fannin...@gmail.com> <mailto:fannin...@gmail.com > <mailto:fannin...@gmail.com>>>> > > 于2023年7月4日周二 19:17写道： > > > > > > > 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 > > > source artifacts, even if the source artifacts are the main point of > > > the vote. > > > > > > When staging RCs for review, I tend to use > > > * dist.apache.org (this is where the source artifacts go anyway) > > > * repository.apache.org (jars) > > > > > > Files on dist.apache.org can be deleted when votes fail. > > > With repository.apache.org, the release is a 2 phase process. You > > > first push to 'staging' and then you can use its Nexus UI to drop or > > > release the staged artifacts after the vote. > > > > > > OpenDAL is mainly in Rust but you also have a large number of language > > > bindings (see libraries list [1]), existing and planned. So > > > presumably, you are using a large number of different packaging tools > > > for your binary releases. Many of us in the IPMC would not be familiar > > > with all these packaging tools. > > > > > > You may already have documentation and if so, could you share a link? > > > > > > If there is no shareable documentation, would you be able to tell us > > > which Crate Registry do you use for your RC Rust binaries? Do we have > > > a custom registry that allows us to remove the binaries for releases > > > that fail? > > > > > > Any information would be appreciated. > > > > > > Regards, > > > PJ > > > > > > [1] https://github.com/apache/incubator-opendal > > > <https://github.com/apache/incubator-opendal> < > https://github.com/apache/incubator-opendal> > <https://github.com/apache/incubator-opendal>> < > > https://github.com/apache/incubator-opendal> > > <https://github.com/apache/incubator-opendal>> < > https://github.com/apache/incubator-opendal>> > <https://github.com/apache/incubator-opendal&gt;>> > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > <mailto:general-unsubscr...@incubator.apache.org> > <mailto:general-unsubscr...@incubator.apache.org > <mailto:general-unsubscr...@incubator.apache.org>> > > For additional commands, e-mail: general-h...@incubator.apache.org > > <mailto:general-h...@incubator.apache.org> > <mailto:general-h...@incubator.apache.org > <mailto:general-h...@incubator.apache.org>> > > > > > >
