<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 14 April 2016 at 15:15, Lance Ball <span dir="ltr"><<a href="mailto:lball@redhat.com" target="_blank">lball@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Stian<div><br></div><div>Thanks for being so patient with my pushback. :)</div><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Apr 14, 2016 at 12:53 AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Adding list back<div><div class="gmail_extra"><br><div class="gmail_quote"><span><span class="">On 13 April 2016 at 21:27, Lance Ball <span dir="ltr"><<a href="mailto:lball@redhat.com" target="_blank">lball@redhat.com</a>></span> wrote:</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 class="gmail_extra"><div class="gmail_quote"><div><br></div><div>I'll take your word for it, but I honestly don'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></span></span><span class=""><div>Releasing everything is going to be a "single" 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></span></div></div></div></div></blockquote><div><br></div><div>Obviously, I agree that micro releases would be good - but I understand your position. All of this is hypothetical at this point anyway, since the node adapter bits I care most about are not yet full citizens and we have a little time to get all of our ducks in a row. </div></div></div></div></blockquote><div><br></div><div>Now that we have someone on the team with NodeJS experience and you guys we hope to make it a full citizen in 2.x, so only a few months from now :)</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 class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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"><div class="gmail_extra"><div class="gmail_quote"><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"><div class="gmail_extra"><div class="gmail_quote"><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"><div>2) There is no change in the adapter between releases of Keycloak server. In this case, it'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 "Keycloak 2.7.0 works with foo-adapter 1.9.1 and greater" any better than "foo-adapter 1.9.1 works with Keycloak 1.9.1 and greater"? 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></span><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'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></div></blockquote><div><br></div></span><div>Absolutely - I understand. We went through a lot of this soul searching with WildFly Swarm recently, and ended up allowing for separate versioning between "core" and "non-core" pieces of the project. There's not a lot of data to go on yet, so we'll see how that turns out. But in this case, wouldn't the most recent Keycloak server always just use the latest version of a given adapter for any new release?</div></div></div></div></blockquote><div><br></div><div>Not sure what you suggesting, but someone (me) has to click the button to release everything. That someone needs to know what version everything should be released as. If everything is released as one version and I can feed that version into my Jenkins job that releases everything it's much simpler.</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 class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>Lance</div><div><br></div></font></span></div></div></div>
</blockquote></div><br></div></div>