On Tue, Apr 12, 2016 at 12:29 AM, Stian Thorgersen <sthorger@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@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@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev

_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev