<div dir="ltr">I'd like to see if we can maintain a single binary that works on 3.6 and 3.7 for ~next month opposed to branching/forking code now.<div><br></div><div>Thought is, check for capability, if it exists use it, if it doesn't error out.</div><div>For something like the User Impersonation feature of "auto_escalate: False" we require newer APIs in 3.7, but we can error out if running on 3.6.  </div><div>This allows the same broker binary to continue to work on 3.6 for next month while 3.7 issues are being flushed out.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 12, 2017 at 9:40 AM, Shawn Hurley <span dir="ltr"><<a href="mailto:shurley@redhat.com" target="_blank">shurley@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/12/2017 09:36 AM, Ryan Hallisey wrote:> Let me know your thoughts.  We can discuss more at today's meeting.<br>
+1<br>
<br>
I would think that we should discuss at either stand up or team meeting tomorrow.<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<wbr>_________________<br>
Ansible-service-broker mailing list<br>
<a href="mailto:Ansible-service-broker@redhat.com" target="_blank">Ansible-service-broker@redhat.<wbr>com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/ansible-service-broker" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/ansible-service-<wbr>broker</a><br>
</div></div></blockquote></div><br></div>