<div dir="ltr">Adding list back<div><div class="gmail_extra"><br><div class="gmail_quote">On 13 April 2016 at 21:27, Lance Ball <span dir="ltr">&lt;<a href="mailto:lball@redhat.com" target="_blank">lball@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Some comments inline...<div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Wed, Apr 13, 2016 at 12:36 AM, Stian Thorgersen <span dir="ltr">&lt;<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>&gt;</span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span><span class="">On 12 April 2016 at 19:25, Lance Ball <span dir="ltr">&lt;<a href="mailto:lball@redhat.com" target="_blank">lball@redhat.com</a>&gt;</span> wrote:<br></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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></span></span><span class=""><div>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.</div></span></div></div></div></blockquote><div><br></div><div>I&#39;ll take your word for it, but I honestly don&#39;t see how pushing a new release of _everything_ can possibly be easier than, for example `npm publish` for a single artifact.</div></div></div></div></blockquote><div><br></div><div>Releasing everything is going to be a &quot;single&quot; 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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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.<br></div></div></blockquote><div><br></div></span><div>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)</div></div></div></div></blockquote><div><br></div></span><div>But how is &quot;Keycloak 2.7.0 works with foo-adapter 1.9.1 and greater&quot; any better than &quot;foo-adapter 1.9.1 works with Keycloak 1.9.1 and greater&quot;? 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.</div></div></div></div></blockquote><div><br></div><div>Being able to grab same version of everything is nice. Being able to not have to upgrade everything is nice. </div><div><br></div><div>Having to figure out what version belongs to what as a first time adapter or when adding a new adapter is not so nice.</div><div><br></div><div>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&#39;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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></span></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><br></div></span><div>It won&#39;t and Keycloak is already becoming a product. Release cadence is 6 weeks in community.</div></div></div></div></blockquote><div><br></div></span><div>To be clear, by &quot;hypothetical situation&quot;, I didn&#39;t mean that Keycloak becoming a product was hypothetical. :) I&#39;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&#39;re going to hit version mismatches then anyway.</div></div></div></div></blockquote><div><br></div><div>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&#39;s my understanding.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888"><div><br></div><div>Lance</div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div></div></div>