[keycloak-dev] Adapter Versioning

[Stian Thorgersen]

Adding list back

On 13 April 2016 at 21:27, Lance Ball <lball at redhat.com> wrote:

> Some comments inline...
>
> On Wed, Apr 13, 2016 at 12:36 AM, Stian Thorgersen <sthorger at redhat.com>
> wrote:
>
>>
>>
>> On 12 April 2016 at 19:25, Lance Ball <lball at redhat.com> wrote:
>>
>>>
>>> 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.
>>>
>>
>> Non-issue as we will push out a release for a critical security fix as
>> soon as possible. Having a single release makes it actually easier to do.
>>
>
> I'll take your word for it, but I honestly don't see how pushing a new
> release of _everything_ can possibly be easier than, for example `npm
> publish` for a single artifact.
>

Releasing everything is going to be a "single" button click. Having the
ability to release micro releases of adapters may be something to consider
in the future if it does indeed become a problem.


>
>
>>
>>
>>> 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.
>>>
>>
>> The plan is to have release notes that cover which adapters have changed
>> and which are required to upgrade (either because backwards compatibility
>> is broken with the server or due to a security fix)
>>
>
> But how is "Keycloak 2.7.0 works with foo-adapter 1.9.1 and greater" any
> better than "foo-adapter 1.9.1 works with Keycloak 1.9.1 and greater"? The
> first scenario is what will happen if adapters march in lockstep with
> Keycloak server, and the second is what will happen if they are released
> only when necessary. In either case, it is possible to be running different
> version numbers for foo-adapter and Keycloak server and still be functional.
>

Being able to grab same version of everything is nice. Being able to not
have to upgrade everything is nice.

Having to figure out what version belongs to what as a first time adapter
or when adding a new adapter is not so nice.

Having to figure out what the version is going to be for each individual
bit when we are doing a collective release is not so nice. Having different
release cycles, etc, etc.. is not so nice. We are a small team with a large
amount of work so we can afford to do this as it's additional time spent
doing releases, which we will be doing every 6 weeks!! so we want to reduce
the pain of doing a release as much as possible.


>
>
>>
>>
>>> 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.
>>>
>>
>>> 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?
>>>
>>
>> It won't and Keycloak is already becoming a product. Release cadence is 6
>> weeks in community.
>>
>
> To be clear, by "hypothetical situation", I didn't mean that Keycloak
> becoming a product was hypothetical. :) I'm saying that product releases
> are much slower, typically, than community releases. Will adapters be
> prevented from publishing an independent security fix in this scenario,
> where the product release cadence has slowed down? If not, we're going to
> hit version mismatches then anyway.
>

Product is different as here you actually have patches that are sent out to
customers. It would not be released as a release until the next micro of
the product as a whole. At least that's my understanding.


>
> Lance
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160414/4fe169e6/attachment-0001.html