[keycloak-dev] Adapter Versioning

[Stian Thorgersen]

All existing adapters follow:
* Release at the same time as server (by the same Jenkins job)
* Same version as the server

Then the improvements we discussed at F2F are:
* Add note to release notes to show what adapters are required to update
* Add a separate adapters guide, with a chapter for each adapter.

That is the simplest and cleanest solution IMO. Further, just to point out
that I want all official Keycloak adapters to follow the same process.

On 12 April 2016 at 21:54, Bruno Oliveira <bruno at abstractj.org> wrote:

> On Tue, Apr 12, 2016 at 2:25 PM Lance Ball <lball at 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)
>

They are actually going to be released by the same process.


> - 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.
>

No, version is the same as the server. Having to install server 1.9.5, jee
adapter 1.8.7, javascript adapter 1.0.5 and nodejs adapter 0.5.0 is just
crazy.


>
>
>>
>> If you've read this far - thanks! Looking forward to your thoughts.
>>
>> Lance
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160413/2691bfb3/attachment-0001.html