-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check for SDK compatibility against current Kuzzle version #1495
Check for SDK compatibility against current Kuzzle version #1495
Conversation
Codecov Report
@@ Coverage Diff @@
## 2-dev #1495 +/- ##
==========================================
+ Coverage 92.82% 92.85% +0.02%
==========================================
Files 98 97 -1
Lines 6678 6621 -57
==========================================
- Hits 6199 6148 -51
+ Misses 479 473 -6
Continue to review full report at Codecov.
|
* | ||
* @returns {Boolean} | ||
*/ | ||
function satisfiesMajor (version, range) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not using semver, which is already included in our package.json?
The way it's currently coded, the compatibility matrix is misleading. I, for one, would have expected a semver range, and I expect to be able to enter something like >=7 <9
for instance, which is a probable value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I choose to use some kind of simplified semver range for now because semver is really slow and this method is called whenever Kuzzle receive a request.
Semver x 176,414 ops/sec ±4.15% (85 runs sampled)
Manual: only major x 776,075,210 ops/sec ±2.42% (90 runs sampled)
We won't need support for this kind of range (>=7 <9
) until v3.
Do you think it's unnecessary ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, this is slow.
My real problem is the syntax similarity with semver, I find that very misleading for future maintenance.
Since the matrix is internal, I think that using a custom format that has nothing to do with semver might be a better idea.
Something like:
{
"js": { "min": 7 },
"csharp": { "max": 2},
"cpp": { "max": 2},
"java": { "max": 3},
"android": { "max": 5},
"go": { "max": 3},
"php": { "max": 4}
}
Of course, we would be able to have both a min and a max value. This should make the version check even faster while unambiguously being different from semver.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you need to remove the auth-local plugin update from this PR
apart from that: 👍
Done @scottinet |
# [2.0.0-rc.2](https://github.com/kuzzleio/kuzzle/releases/tag/2.0.0-rc.2) (2019-11-05) #### Breaking changes - [ [#1500](#1500) ] Remove Dsl constructor from plugin context ([Aschen](https://github.com/Aschen)) - [ [#1489](#1489) ] Drop support for socket.io ([scottinet](https://github.com/scottinet)) - [ [#1491](#1491) ] Remove strategy constructors support ([Aschen](https://github.com/Aschen)) - [ [#1476](#1476) ] Change Document controller m* routes returns & fix SDK functional tests ([Aschen](https://github.com/Aschen)) #### Bug fixes - [ [#1512](#1512) ] Fix subscribing with a dead connection ([benoitvidis](https://github.com/benoitvidis)) - [ [#1507](#1507) ] Properly destroy a user after a credentials creation failure ([scottinet](https://github.com/scottinet)) - [ [#1483](#1483) ] Fix socketio connections leak & deactivate this protocol by default ([scottinet](https://github.com/scottinet)) #### New features - [ [#1502](#1502) ] Add a new "document:exists" API route ([scottinet](https://github.com/scottinet)) - [ [#1501](#1501) ] Add collection delete ([Aschen](https://github.com/Aschen)) - [ [#1499](#1499) ] Expose an Elasticsearch client constructor in plugin context ([Aschen](https://github.com/Aschen)) - [ [#1484](#1484) ] Upgrade script ([scottinet](https://github.com/scottinet)) #### Enhancements - [ [#1510](#1510) ] Mapping - enable dynamic templates ([benoitvidis](https://github.com/benoitvidis)) - [ [#1495](#1495) ] Check for SDK compatibility against current Kuzzle version ([Aschen](https://github.com/Aschen)) - [ [#1498](#1498) ] Add highlight to search results ([Aschen](https://github.com/Aschen)) - [ [#1488](#1488) ] Add kuzzle version to the dumped informations ([scottinet](https://github.com/scottinet)) - [ [#1481](#1481) ] Error codes normalization ([scottinet](https://github.com/scottinet)) - [ [#1478](#1478) ] Error codes redux ([scottinet](https://github.com/scottinet)) ---
What does this PR do ?
v1: #1494
Now Kuzzle will check the
volatile.sdkName
header to ensure that the current SDK is compatible against the current Kuzzle version.For Kuzzle v1 SDKs, the
sdkVersion
property is present. So when the property is present, we assume that the SDK is incompatible.For Kuzzle v2 SDKs, a compatibility matrix has been added. It's checking the
volatile.sdkVersion
property and works with simplified semver ranges.Example compat matrix:
Example
sdkName
volatile property:js@7.4.2
Other changes