Reconsider major.minor pinning

[blakeembrey]

I brought this up before offline, but I want to post it here to discuss it thoroughly. The current implementation pins to major.minor which blocks people from typing anything with a smaller version. This is a bit of an issue for anyone wanting to type/use pre-release software, or if something needs to be added for an actual patch release (though that breaks semantic versioning, not everyone follows it correctly - including TypeScript - and it could occur more likely on 0.x versions where semver doesn't actually apply).

The way this is solved in Typings is by using the build metadata part of semver. Specifically, 2.0.0+timestamp.

[RyanCavanaugh]

I don't see how this is going to be an issue in practice (or I'm misunderstanding what you're saying here). Is there anyone who actually needs to target a specific patch version of a library with a specific typings file? That seems theoretical at best.

[blakeembrey]

Yes. Gulp is currently in an alpha, and someone recently contributed typings for it.

[RyanCavanaugh]

It's an alpha, without a major version bump, with breaking changes?

[blakeembrey]

No, it's 4.0.0-alpha - but I assume you don't want people installing 4.0.0-alpha typings just because 4.0.0-beta is now out with more breaking changes.

[blakeembrey]

Or the granularity does not matter? It's the same as though 4.0 stable is just released, you won't be able to differentiate between 4.0.0 and 4.0.0-alpha in case the community has not caught up.

[blakeembrey]

Also, I think you'll need to do some tagging trickery here too - otherwise people doing npm install @types/gulp would currently be receiving the alpha typings of 4.0 (because the version has been changed to 4.0.0) while everyone should probably be using 3.x typings.

Edit: If you decide the granularity does not matter, let's make an issue tracking the tagging - we definitely don't want the @latest tag pointing to pre-releases.

[RyanCavanaugh]

We can funnel through any prerelease metadata, so if the types file says it's for 4.0.0-alpha we'll publish it at 4.0.x-alpha and @latest (which would be the default) would be published for the newest version lacking a prerelease tag.

[blakeembrey]

Seems reasonable. Still a little scared of it since it's against semver and I haven't though about what might happen, but at least proxying pre-release info is a plus 👍

[blakeembrey]

Now that even TypeScript has been bitten by the bad semver implementation with microsoft/TypeScript#14555, is it possible to open this discussion up to finding a solution? Using the pre-release metadata might be a possible approach using NPM if there's a way to ensure breaking changes in the pre-release don't satisfy (^).

Edit: There's not a way that I have found yet, FYI. Pre-release versioning seems like a pain and it may be worth asking NPM for guidance/changes in this area so that ^2.2.0-v1 does not install 2.2.1 or 2.2.0-v2, or so the default with --save of a pre-release does not include ^ instead.

[blakeembrey]

Actually, I think I just realised how this can be done with NPM and zero changes required. According to https://docs.npmjs.com/misc/semver#prerelease-tags and semver. Use the patch and prelease versions. The pre-release represents revisions to the definition, while the patch becomes the mechanism for communicating breaking changes.

semver.maxSatisfying(['7.0.2-v1', '7.0.1-v1'], '^7.0.1-v1')

Edit: This is only from the publishing side. I figure the tooling side will be up to MicroSoft on how the definition communicates a breaking change to the publisher. It also relies on you sticking with pre-release versioning, because once a stable version that's larger appears it'll use that. Weird right? You'd think if you installed a pre-release you should probably be stuck on it until you explicitly move to the stable versions.