9:54 p.m.
On Tue, Apr 12, 2016 at 2:25 PM Lance Ball <lball(a)redhat.com> wrote:
Hi all
I've been emailing with Stian about versioning in the "Node.js adapter
releases" thread, but as he pointed out, some of my concerns are broader
than just Node.js and so I am broadening the conversation a bit.
Background: I am working as part of a Node.js RHT "middleware" team to,
among other things, contribute towards the development of Node.js modules
for our existing JBoss technologies. As part of this, we're doing what we
can for the Keycloak Node.js pieces.
As it stands now, I understand that versioning of adapters must remain in
lockstep with Keycloak core. I understand the motivation for this, but want
to push back on this just a little bit, and open it up for discussion.
I see a couple of scenarios where this is potentially problematic. I am
using Node.js and NPM here, but I think the concerns should apply to any
adapter that is part of an ecosystem outside of Java.
1) There is a security flaw in some 3rd party dependency of the adapter,
discovered the day of a Keycloak core release. This renders the "latest"
version of an adapter useless until a new Keycloak server is released. I
understand that the release cadence is anticipated to be approximately
every 6 weeks (which is laudable), but still that's > 1 month that users
have to wait for a security fix.
In my opinion it depends how critical and exploitable is the vulnerability.
For critical updates, I'd say that the adapter should be release ASAP and
the patch number increased and released. For example: vulnerability found
at 0.0.16 we just bump it up to 0.0.17 and release.
2) There is no change in the adapter between releases of Keycloak server.
In this case, it's not necessarily a problem to release a new adapter
version, but it seems noisy and pointless if the bits are exactly the same.
When we look at version numbers, they are typically MAJOR.MINOR.PATCH with
possibly a pre-release suffix like -Alpha1. I would like to discuss the
possibility for adapters to issue patch level releases independent of a
server release. This would allow for MAJOR.MINOR versions to remain
consistent so to communicate compatibility with a given Keycloak server
version. But would provide flexibility for adapters to deal with both
issues noted above.
I'm +1 on keeping independent version numbers from the server and state
something like connect-keycloak v0.0.17 is compatible with Keycloak server
1.9.2.Final for example. But I'm -1 on independent release dates — unless
we have a critical security fix.
If we release whenever we want the adapters, would be hard to test, because
we don't have bandwith for it. I see as something which could become out of
control like v0.0.15, v0.0.16, v0.0.17 is compatible with KC 1.9.2, but
v0.0.18 only works with KC 2.0.x.
And just for the sake of argument, let's look at a hypothetical situation
where Keycloak is baptized a Product, and the release cadence slows down
significantly to every 12-18 months. What if a major security flaw is
discovered in an adapter? Should this trigger a new release of Keycloak
server itself? Would it not be better to allow the adapter to issue a patch
level release instead?
+1 for just the adapter issue a patch level release.
tl;dr my personal opinion is (anything that I'm going to say here can be
innacurate, because I don't have the whole context about the conversations
during the F2F):
- Adapters should be released on exactly the same dates as the server (with
one single exception, critical security fixes)
- The version number should be independent, in this way we state something
like Node.js adapters version 0.0.17 are fully compatible with KC 1.9.x.
If you've read this far - thanks! Looking forward to your thoughts.
Lance
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev