On Wed, 26 Feb 2014 16:04:38 -0600
Chris Behrens <cbehr...@codestud.com> wrote:
> 
> This thread is many messages deep now and I’m busy with a conference
> this week, but I wanted to carry over my opinion from the other “v3
> API in Icehouse” thread and add a little to it.
> 
> Bumping versions is painful. v2 is going to need to live for “a long
> time” to create the least amount of pain. I would think that at least
> anyone running a decent sized Public Cloud would agree, if not anyone
> just running any sort of decent sized cloud. I don’t think there’s a
> compelling enough reason to deprecate v2 and cause havoc with what we
> currently have in v3. I’d like us to spend more time on the proposed
> “tasks” changes. And I think we need more time to figure out if we’re
> doing versioning in the correct way. If we’ve got it wrong, a v3
> doesn’t fix the problem and we’ll just be causing more havoc with a
> v4.

So I guess I agree tasks is something we should develop further and
that makes significant non backwards compatible changes to the API -
which is the major reason why we delayed V3. And its really important
that we get those changes right so we don't need a v4.

However, keeping V3 experimental indefinitely doesn't actually remove
the dual maintenance burden. The only way to do that is eventually
remove either the V2 or V3 version or do the suggested backport. 

We've pretty well established that starting a fresh v3 API is a
multi cycle effort. If we remove the V3 api code in Juno and then
start working on a new major version bump at a later date at say L or
M it'll be another multi cycle effort which I doubt would be
feasible, especially with people knowing there is the real risk at the
end that it'll just get thrown away. 

And the alternative of not removing V3 leaves the extra maintenance
burden. So whilst I agree with making sure we get it right but I'm
wondering exactly what you mean by taking more time to figure out
what we're doing - is it removing the V3 API code and just coping
with extra maintenance burden? Or removing it and then trying to do
a big multi cycle effort again a few cycles down the track?

Chris

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to