> 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> 于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>>: > > > 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>> 于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>>>: > > > > > > 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 > > > > > > > 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 > > > > > > > 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 > > > > > > > 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 > > > > > > > > > > > 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>> > > [2] https://opendal.apache.org/download < > https://opendal.apache.org/download> < > > https://opendal.apache.org/download> < > https://opendal.apache.org/download>> > > [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>> > > > > > > > > > > > > > > PJ Fanning <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>> > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: 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> > > > > > >
