It sounds like the consensus on the release thread might be to skip the JS export for 1.0.0.
At this point, I think it would be simpler to try to keep library versions in sync as part of the same release process, but I agree that all the issues raised here might cause headaches for consumers of JS (and maybe other libraries). If we get feedback accordingly we can potentially revisit the strategy. My main concern with separate release cycles is it makes it less likely that some of the languages with less active development would ever get released. -Micah On Fri, Jul 10, 2020 at 12:04 PM Weston Pace <weston.p...@gmail.com> wrote: > Just to be more specific. Since most JavaScript packages follow semantic > versioning that means that a change from 1.0.0 to 2.0.0 would imply that > there were breaking changes in the API (i.e. not backwards compatible). By > default, when declaring a dependency on a package that has a 1.X release, > the JavaScript package managers will add a dependency range of >= 1.X and < > 2.X. This may slow adoption of newer releases as many groups just run "npm > upgrade" on a semi-regular basis to make sure they stay current and this > command would never upgrade such a dependency from 1.X to 2.X. > > For direct consumers of Arrow I would think it is probably not too big of > a deal. If you are directly consuming a library you probably pay some > general attention to its development (although JS developers may do this > less than others as they tend to have so many dependencies). Such > developers would likely notice at some point that they are well behind and > would upgrade to the latest after doing a bit of research to make sure the > breaking changes (which they won't find) don't apply to them. > > For developers that are consuming Arrow transitively they are likely to > never upgrade their version of Arrow unless the library in the middle > happens to have a new release that specifically depends on a newer version > of Arrow. > > If an app depends on Arrow through multiple paths (i.e. the root project > depends on several libraries, each of which depends on Arrow) then it makes > it more likely an app has to bundle and include multiple versions of > Arrow. For backend apps this isn't too big of a deal and it's pretty > expected at this point that you will have multiple versions of some > libraries. For frontend apps developers are often a bit more sensitive to > the size of the final bundle and so having to bundle multiple versions of > Arrow will be a bit of a pain and they will probably have to find some way > to manually force the older packages to use the newer version. > > This is all hypothetical, it's possible none of these issues arise, and if > they do they are not serious, but these are just some things I have seen > from doing JS development for a while. > > -Weston > > On Fri, Jul 10, 2020 at 8:39 AM Paul Taylor <ptaylor.apa...@gmail.com> > wrote: > >> Hey Micah, >> >> npm allows you to set the version to anything you wish, but semantic >> versioning[1] is the convention. A few large-ish packages don't follow >> this (closure-compiler uses a timestamp as its version), but the tooling >> strongly nudges package owners and consumers towards semver. >> >> 1.0.0 releases are a significant milestone to npm. Before 1.0.0, npm >> enforces strict versioning -- users who depend on `^0.8.0` will receive >> 0.8.0, even if there's a `0.9.0` or `0.9.1` available. After 1.0.0, >> users who depend on `^1.0.0` will receive any newer minor and patch >> releases (but not major version bumps). In this sense, Arrow doing major >> version bumps is fine, if a bit foreign to most node devs. >> >> I worry more about releasing a 1.0.0 with type definitions that require >> library consumers use a TypeScript compiler that's a year old (aka a >> decade in JavaScript-years ;]). Bumping to 1.0.0 communicates a level of >> maturity the JS project still needs to achieve IMO. >> >> I'm personally ambivalent and will defer to the Arrow community on >> versioning, but these are the general expectations of larger packages in >> the node community as I understand them. >> >> Best, >> >> Paul >> >> 1. https://docs.npmjs.com/about-semantic-versioning >> >> >> On 7/9/20 10:34 PM, Micah Kornfield wrote: >> > Hi Paul, >> > I'm not sure if this was ever resolved, but I think the plan going >> > forward is to start bumping major versions on each release. Would NPM >> > allow such changes in that case? >> > >> > Cheers, >> > Micah >> > >> > On Wed, Jul 1, 2020 at 9:23 AM Paul Taylor <ptaylor.apa...@gmail.com >> > <mailto:ptaylor.apa...@gmail.com>> wrote: >> > >> > The TypeScript compiler has made breaking changes in recent >> releases, >> > meaning we can't easily upgrade past 3.5 and projects on 3.6+ can't >> > compile our types. >> > >> > I'm working on upgrading our tsc dependency to 3.9. The fixes could >> > include a few backwards-incompatible API changes, and might not be >> > done >> > in time for the general Arrow 1.0 release. >> > >> > JS shouldn't block the 1.0 release, so can we exclude JS from 1.0 >> > if the >> > fixes aren't ready by then? npm's semantic versioning allows >> breaking >> > changes in any version before 1.0, but not between minor versions >> > after >> > 1.0. I've heard directly from some of our JS users who'd prefer if >> we >> > made these changes before bumping to 1.0 on npm. >> > >> > Thanks, >> > >> > Paul >> > >> >
