A truncate() or dec() method could be very useful

[ronkorving]

I have a situation where I have an API version and my web frontend is aware of that version at application start. When doing live updates of the backend, I want to be able to decide which connections coming from frontend can be considered API stable with my backend (does this make sense?).

Example

1. Server runs version 0.1.2
2. User starts and thus now runs on version 0.1.2
3. Server application gets upgraded to 0.1.3
4. User interacts with server, but now there is a version mismatch.

In this case, I want to say 0.1.2 satisfies 0.1.x, so the APIs are compatible. Because all version information comes from variables here, I'm wondering how I should go about generating the 0.1.x range, or >=0.1.0 <0.2.0 range. To generate the latter I was thinking of this:

var version = '0.1.2';
var str = '>=' + semver.truncate(version, 'patch') + ' <' + semver.inc(version, 'minor');
// now do a satisfies check

The inc() method already exists, but truncate() does not. Do you think it would make sense to add a method like that?

[isaacs]

Why not just use range = '~' + version or range = '^' + version?

[ronkorving]

Because I also want downward compatibility. So I don't want "0.1.2 and later", I want "0.1.x".

[isaacs]

Wait, so... how are you generating this range, then?

I'd think it would work like this:

1. The server has a specific version, or implements multiple versions.
2. The client says "I need a version matching $range"
3. The server says either:
   1. Here's a response from a service $version that matches it, or
   2. 406, Sorry, no service can provide a response in a way that satisfies your request.

Is this how it works? So, who's generating this range? The server or the client?

[ronkorving]

It's working a bit reverse, let me try again and be more coherent this time:

1. The server has a specific version
2. The client says "when I started this app, you said you were 1.2.3"
3. The server says either:
   1. Version 1.2.3 you say? That's compatible with me (because I am 1.2.4 now), so let's do business.
   2. Sorry, I'm version 1.3.0 now, you'll want to update your client code so we can talk again.

So at point 3, it's the server that has the range "1.2.x" (in the case of point 3.1) or "1.3.x" (in the case of point 3.2).

[isaacs]

Why not just do this?

var versionClientGaveMe = req.headers['x-start-version-or-whatever'];
var myVersion = server.versionOrWhatever;
var isOk = semver.satisfies(myVersion, '^' + versionClientGaveMe);

How often do you decrement the version running on the server?

[ronkorving]

We roll out releases very often, and if post-release any issues are found, we can rollback the release to a previously installed version.

[isaacs]

if a post-release issue is found, doesn't that mean that you want the client to roll back?

[isaacs]

(didn't mean to close. this isn't a terrible feature idea, i'm just trying to figure out the use case a little bit.)

[ronkorving]

You make a good point actually. "better safe than sorry" is a totally acceptable approach here. You've convinced me. I will go for your suggestion.

[isaacs]

Well, it's still a good feature idea, probably, and not terribly hard to do. I'll post a new issue without the use case you presented here :)

[ronkorving]

Cool, thanks :)