<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><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><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><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>