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