Thank you, Wes. Could you point me to what preparations we need to make now and how we can make a patch release in the future?
On Nov 10, 2021 at 17:34:44, Wes McKinney <wesmck...@gmail.com> wrote: > I don't see a problem with making JS-only patch releases. There's some > work to facilitate the release management but if it's a source-only > release it shouldn't be _that_ difficult. > > On Fri, Nov 5, 2021 at 9:50 AM Dominik Moritz <domor...@apache.org> wrote: > > > Hi Neal, > > > Great questions. We could potentially add an integration test for major > > bundlers. However, then we would also need a way to test these packages in > > different environments like browsers and that’s a lot of work that I’m not > > sure will be proportional to the benefit. The issue in my experience is > > that the JS ecosystem is very diverse and there are many bundlers and > > different ways to consume packages (just look at the list of configurations > > we generate in https://github.com/apache/arrow/tree/master/js#packaging > and > > that’s ignoring some other es variants like es2017 and separate bundles for > > browsers and node; or Deno in the future maybe). It’s really hard to test > > all of these things automatically. > > > I think pre-releases would go a long way to working packages when we make a > > major release but I suspect there will always be some use cases we did not > > anticipate. I made two JIRAs for pre-releases: > > https://issues.apache.org/jira/browse/ARROW-14508 and > > https://issues.apache.org/jira/browse/ARROW-14507. > > > Best wishes, > > Dominik > > > On Nov 5, 2021 at 10:00:10, Neal Richardson <neal.p.richard...@gmail.com> > > wrote: > > > > Not expressing an opinion on the original question, but if the problem is > > > "not getting everything right the first time", what can be done to reduce > > > the likelihood of getting things wrong? Other languages/implementations > > > have extensive CI and nightly builds, some of which test different > > > packaging scenarios and integration testing with other projects (e.g. > > > spark, dask) that we don't want to break support with. Are there > additional > > > JS builds we could add that would increase our confidence in the quality > of > > > our releases? > > > > > > Neal > > > > > > On Thu, Nov 4, 2021 at 12:04 PM Dominik Moritz <domor...@apache.org> > > > wrote: > > > > > > Dear Arrow Devs, > > > > > > > > > We would like to ask to have independent patch releases for the Arrow JS > > > > > > library. Having independent patch releases will help us resolve issues > that > > > > > > only become visible when people start to use the library. The JS > ecosystem > > > > > > is diverse and only recently has become more standardized. Therefore, it > > > > > > has been difficult to get everything right the the first time, which had > > > > > > led to frustrations by many users. It would really help us if we could > make > > > > > > patch releases to fix critical issues without waiting for other libraries > > > > > > to be ready for a new release as well. > > > > > > > > > Thank you for considering the request, > > > > > > Dominik for the Arrow JS devs > > > > > > > > > > >
