<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 12, 2016 at 2:25 PM Lance Ball &lt;<a href="mailto:lball@redhat.com" target="_blank">lball@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all<div><br></div><div>I&#39;ve been emailing with Stian about versioning in the &quot;Node.js adapter releases&quot; 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.</div><div><br></div><div>Background: I am working as part of a Node.js RHT &quot;middleware&quot; team to, among other things, contribute towards the development of Node.js modules for our existing JBoss technologies. As part of this, we&#39;re doing what we can for the Keycloak Node.js pieces.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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 &quot;latest&quot; 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&#39;s &gt; 1 month that users have to wait for a security fix.</div></div></blockquote><div><br></div><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>In my opinion it depends how critical and exploitable is the vulnerability. For critical updates, I&#39;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. </div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>2) There is no change in the adapter between releases of Keycloak server. In this case, it&#39;s not necessarily a problem to release a new adapter version, but it seems noisy and pointless if the bits are exactly the same.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>I&#39;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&#39;m -1 on independent release dates — unless we have a critical security fix.</div><div><br></div><div>If we release whenever we want the adapters, would be hard to test, because we don&#39;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.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>And just for the sake of argument, let&#39;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?</div></div></blockquote><div><br></div><div>+1 for just the adapter issue a patch level release.<br></div><div><br></div><div>tl;dr my personal opinion is (anything that I&#39;m going to say here can be innacurate, because I don&#39;t have the whole context about the conversations during the F2F):</div><div><br></div><div>- Adapters should be released on exactly the same dates as the server (with one single exception, critical security fixes)</div><div>- 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>If you&#39;ve read this far - thanks! Looking forward to your thoughts.</div><div><br></div><div>Lance</div><div><br></div></div>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></blockquote></div></div></div>