> Could you combine 1 and 4?
> Deprecate not specifying the version, but pin to the oldest one for now?
> That way users get the warnings that they need to adapt, but things keep
> working? Could be switched to just 4 after a few months.

This is similar to what I would like to suggest. But I would leave the
pin at the current version we have right now (which is 1.9 [1])
instead of the earliest one; We then add some deprecation messages
when the user do not specify a version. Otherwise we may break people
that are currently using the features up to version we have pinned
right now.

In the long run I think that option 4. is the best option. As @Jim
already pointed out from a UX point of view it's not that it will make
anything worse since we already require a number of arguments. This
will also makes users understand the versions we provide and pin his
environment at a specific version, that way it will not break due
future changes to our API and he/she can, at his/her own pace, update
his/her systems to a newest version knowing that he/she already has a
version that works.

> I say that having just added some IP addresses to a server with iproute2,
> which has been telling me for probably 10 years that _not_ adding /32
> to single IP's will eventually be deprecated...

Heh we should be faster than that (-:



OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to