On Tue, Apr 12, 2016 at 12:29 AM, Stian Thorgersen <sthorger(a)redhat.com>
wrote:
Having the same version makes it much easier for people to grab a
version
they know works with a specific Keycloak version. It also makes it simpler
when we release.
Keycloak has a 6 week release cadence
While this probably works most of the time, i'm wondering what happens,
for example, if in the node.js adapter there is a security vulnerability in
one of the dependent packages that is discovered a couple days after a
release, would you then need to create a new release of all of Keycloak?
that is fine, i'm just wondering if thats what would happen since that
could be a real possibility. so for an issue like this:
https://issues.jboss.org/browse/KEYCLOAK-2798. a full keycloak release
would need to happen then?
*everything i said above only applies if that node adapter is a full class
citizen, obviously "community" things are different *
and adapters shouldn't be released more frequently. Rather they
should be
released at the same time as the server and by the same release job in
Jenkins.
To become a first class citizen an adapter has to:
* Release at same time as Keycloak server (every ~6 weeks). We test and
release everything as a bundle and don't have the resources to maintain
separate release cycles. I also want all adapters to be consistent here.
* Documentation - we're going to have a adapters documentation, it will
have a separate chapter for each adapter. Each adapter chapter will have a
getting started and a reference/developer guide. There's also need for the
relevant api docs in whatever format is most popular for a specific language
* Examples - not sure where these will live. Maybe all examples for all
adapters are in one repo
Any changes to the above has to be raised. If you really want to discuss
that then send a generic message to keycloak-dev list, basically don't
include NodeJS in the title ;).
On 11 April 2016 at 20:27, Lance Ball <lball(a)redhat.com> wrote:
> I agree that keeping version numbers consistent might be questionable.
> There is the big bump as Bruno notes, but also the npm modules need to be
> able to publish in the absence of a keycloak release in the event that
> there are bugs which need to be addressed in an adapter but not in keycloak
> itself - e.g.
https://issues.jboss.org/browse/KEYCLOAK-2798.
>
> Lance
>
> On Mon, Apr 11, 2016 at 2:21 PM, Bruno Oliveira <bruno(a)abstractj.org>
> wrote:
>
>> +1 for consistency and release dates. But I'd keep the release version
>> independent, move from 0.0.16 to 1.9.2 for example, is a huge bump.
>>
>> On Mon, Apr 11, 2016 at 1:43 PM Stian Thorgersen <sthorger(a)redhat.com>
>> wrote:
>>
>>> We discussed this at the f2f and I believe we should keep it consistent
>>> across all adapters.
>>>
>>> The decision was to have all adapters released when the server is
>>> released and they will have the same version numbers. We will also make
>>> sure release notes mark which adapters have changed and also which are
>>> required to update (either due to compatibility changes or security related
>>> fixes).
>>>
>>> So I'd like the ability to release nodejs adapters at the same time I
>>> do the release of the server.
>>>
>>> We can certainly discuss changes to the above, but it should be
>>> consistent for all our adapters.
>>> On 11 Apr 2016 17:09, "Bruno Oliveira" <bruno(a)abstractj.org>
wrote:
>>>
>>> Good morning,
>>>
>>> Today I was chatting with Lance about the release cadence for Node.js
>>> adapters.
>>>
>>> My initial idea was to release the adapters at exactly the same release
>>> dates as the official Keycloak release in order to guarantee compatibility.
>>> For critical/urgent patches, we just release those modules based on our
>>> judgment.
>>>
>>> Lance would like more flexibility between those releases. For example,
>>> release npm modules before the official release for situations where a user
>>> wants some new capability that is perhaps unrelated to changes in KC
>>> itself e.g. a move to promises.
>>>
>>> I don't have any problems on keeping Node.js adapters' release
>>> independent from official KC release, but would like to hear more opinions
>>> about it.
>>>
>>> --
>>>
>>>
>>> -
>>> abstractj
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev