Again, just another quick response, but if we can find a way to merge v2 into the current v3 code, so that we don't have dual maintenance, that would be really nice.
> On Feb 26, 2014, at 5:15 PM, Christopher Yeoh <cbky...@gmail.com> wrote: > > 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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
