Hi Paul,
Is there a github location where I could track this upgrade? I'm interested
in using arrow JS in a project that is currently migrating to tsc 3.9, so I
am definitely keen on seeing the JS version continue forward.
Regards,
Naveen Michaud-Agrawal
On Wed, Jul 1, 2020 at 12:23 PM Paul Tay
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
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,
th
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 r
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 wrote:
> The TypeScript compiler has made breaking changes
Since publishing artifacts to NPM is somewhat independent from the
Apache source release, if you aren't ready to push to NPM then the
release manager can just not push the artifacts
Note that the plan hasn't been to go from 1.0.0 to 1.1.0, rather that
almost every Apache release (aside from patch
