Open Stack

HI

> Hi, I'd like to make sure I understand. Is it the case that ideally, if we
> could go back in time, we'd like to change the client so it defaults to 1.1?

AFAIUI, yes

> But since we can't, the next client that we ship/release will have the most
> reasonable oldest version? If so, then since the most recent client shipped
> is at 1.6, then I think we should put it back to 1.6 even though it is 1.9
> on master. Regardless of whether there are no backwards incompatible changes
> between 1.6 & 1.9 -- because we need to stick to some way-of-doing-things,
> and if we use 1.9, I suspect it will be confusing. At least 1.6 was what we
> had at the end of kilo.
>

The reason why I think we should release with 1.9 is because:

1) It's already on master and people may be using it already

2) It's compatible with the previous version that has been released
already (1.6).

So it won't break neither users that just get it from pip nor users
that clone the git repository.

> What we're saying is that for M*, N*, O*, ..., the version used in the
> client will be the higher of server's MIN_VER_STR or 1.6, right?
>

It's a suggestion, if we all agree that the minimal version (1.1) is
the ideal version to the client to be pinned with when no other
version is specified, how can we best warn the users that we are going
to pin to this version for the future releases ?

Maybe we don't need to do that, but would be good to discuss and have
a consensus about it.

>
> Hey Lucas, Maybe I missed something about the client. If no version is
> specified to the (next-released) client, won't it use 1.6? How are we going
> to move it back to 1.1?
>

Yeah *right now* with the last released version if you don't specify a
version it will use 1.6. With the current code in the git repository
the version will used will be 1.9 if no other is specified.

About how we are going to move it back was my question as well. If we
all agree in moving it to 1.1 when no version is specified how we can
best warn the users that we are going to do that? Since it might break
their workflow. Maybe we shouldn't move it back, but let's keep the
conversation going so we can solve this.

Cheers,
Lucas