<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 August 2015 at 13:08, Lucas Alvares Gomes <span dir="ltr"><<a href="mailto:lucasagomes@gmail.com" target="_blank">lucasagomes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">HI<br>
<span class=""><br>
> Hi, I'd like to make sure I understand. Is it the case that ideally, if we<br>
> could go back in time, we'd like to change the client so it defaults to 1.1?<br>
<br>
</span>AFAIUI, yes<br>
<span class=""><br>
> But since we can't, the next client that we ship/release will have the most<br>
> reasonable oldest version? If so, then since the most recent client shipped<br>
> is at 1.6, then I think we should put it back to 1.6 even though it is 1.9<br>
> on master. Regardless of whether there are no backwards incompatible changes<br>
> between 1.6 & 1.9 -- because we need to stick to some way-of-doing-things,<br>
> and if we use 1.9, I suspect it will be confusing. At least 1.6 was what we<br>
> had at the end of kilo.<br>
><br>
<br>
</span>The reason why I think we should release with 1.9 is because:<br>
<br>
1) It's already on master and people may be using it already<br>
<br>
2) It's compatible with the previous version that has been released<br>
already (1.6).<br>
<br>
So it won't break neither users that just get it from pip nor users<br>
that clone the git repository.<br></blockquote><div><br></div><div>The order of my preference is 1.1 (which is unrealistic as I mention below), 1.6 (because that's what the client had in kilo release and is the 'closest' version to the server's 1.1), then 1.9 for the reasons you mentioned above, then 1.10 just cuz it is the last version that is backwards compatible :-)</div><div><br></div><div>Devananda has a patch[0] that changes the client to 1.6, but the reviewers' comments there point to the mailing list (here) wrt deciding what it should be so what do other folks think?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> What we're saying is that for M*, N*, O*, ..., the version used in the<br>
> client will be the higher of server's MIN_VER_STR or 1.6, right?<br>
><br>
<br>
</span>It's a suggestion, if we all agree that the minimal version (1.1) is<br>
the ideal version to the client to be pinned with when no other<br>
version is specified, how can we best warn the users that we are going<br>
to pin to this version for the future releases ?<br>
<br>
Maybe we don't need to do that, but would be good to discuss and have<br>
a consensus about it.<br></blockquote><div><br></div><div> I think 1.1 (the server's MIN_VER_STR) is the ideal version for the client, but I think we missed the boat on that. I don't think it makes much sense to change things so that the client uses that version in some future release. The reason being is that kilo was released with the client defaulting to 1.6. For everyone in cloudland not explicitly specifying a version, they are using 1.6. And what is different in 1.6 than 1.1 -- we renamed NOSTATE to AVAILABLE state. I don't think it is worth breaking existing applications to deprecate/go back to 1.1.</div><div><br></div><div>(A separate discussion I'd like to have, is when do we want to change the server's MIN_VER_STR from 1.1 to eg 1.6 or even gasp, 1.11 when ENROLL made its appearance).</div><div><br></div><div>--ruby</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/208102/">https://review.openstack.org/#/c/208102/</a></div></div></div></div>