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> >
