[keycloak-dev] Adapter Versioning

Wed Apr 13 07:45:09 EDT 2016

On 13 April 2016 at 13:37, Bruno Oliveira <bruno at abstractj.org> wrote:

>
>
> On Wed, Apr 13, 2016 at 1:41 AM Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>> 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.
>>
>
> I'm sorry but I have to disagree, we already do it for years with 3rd
> party dependencies into our projects. For security fixes where you have the
> adapter and the server with version as 1.9.2.Final, we cannot bump up the
> version of the server because the adapter has a critical security issue and
> have to be released.
>
> But if this is a decision already taken, I'm not taking this road
> discussing why I think it's bad.
>

The decision has been made, but nothing is set in stone. I suggest we try
the approach we decided at the f2f and adjust later if it becomes a problem.

>
>>
>>>
>>>
>>>>
>>>> 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/97c7a44d/attachment.html 