Operationally they'll need to be able to make the change in a way that it can be sequenced. We don't have a concept of simultaneous tied changes. So a the change you describe would need to look like:
Land change to openstack-common to add something new Land changes to dependent projects to use that new thing Land change to openstack-common to remove now deprecated thing. As a related note, I'm going to get the current repo moved in to gerrit today or tomorrow. Monty On 01/03/2012 11:54 AM, Ewan Mellor wrote: > I'd love to see openstack-common get off the ground, so I'm all in favor of > this. > > One question: why do you feel that you need such strong backwards > compatibility? If someone makes a change in openstack-common and makes > simultaneous changes in all OpenStack projects to match, isn’t that > sufficient? > > Ewan. > >> -----Original Message----- >> From: openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net >> [mailto:openstack-bounces+ewan.mellor=citrix....@lists.launchpad.net] >> On Behalf Of Mark McLoughlin >> Sent: 03 January 2012 08:58 >> To: openstack@lists.launchpad.net >> Cc: Jason Koelker >> Subject: [Openstack] openstack-common >> >> Hey, >> >> As Jason says - another year, another openstack-common thread! :-) >> >> I've just written up the plan Jason and I have for openstack-common: >> >> http://wiki.openstack.org/CommonLibrary >> >> (also pasted below to make it easier to reply to) >> >> I guess what we're trying to do is quickly get this thing into good >> enough shape to do a first release. Even if that release only contains >> a >> handful of APIs, but they meet the criteria below, then we'll have a >> really solid foundation to build on. >> >> Thoughts? >> >> Cheers, >> Mark. >> >> The openstack-common project intends to produce a python library >> containing >> infrastructure code shared by OpenStack projects. The APIs provided by >> the >> project should be high quality, stable, consistent and generally >> useful. >> >> The existence of an API in openstack-common should be indicitative of >> rough >> consensus across the project on that API's design. New OpenStack >> projects should >> be able to use an API in the library safe in the knowledge that, by >> doing so, >> the project is being a good OpenStack citizen and building upon >> established >> best practice. >> >> To that end, a number of principles should be adhered to when >> considering any >> proposed API for openstack-common: >> >> 1) The API is generally useful and is a "good fit" - e.g. it doesn't >> encode >> some assumptions specific to the project it originated from, it >> should >> follow a style consistent with other openstack-common APIs and >> should >> fit generally in a theme like error handling, configuration >> options, >> time and date, notifications, WSGI, etc. >> >> 2) The API is already in use by a number of OpenStack projects >> >> 3) There is a commitment to adopt the API in all other OpenStack >> projects >> (where appropriate) and there are no known major blockers to that >> adoption >> >> 4) The API represents the "rough consensus" across OpenStack projects >> >> 5) There is no other API in OpenStack competing for this "rough >> consensus" >> >> 6) It should be possible for the API to evolve while continuing to >> maintain >> backwards compatibility with older versions for a reasonable >> period - e.g. >> compatibility with an API deprecated in release N may only be >> removed in >> release N+2 >> >> There have been several attempts at kick-starting openstack-common, >> each attempt >> beginning with moving a number of existing APIs from Glance or Nova >> into a new >> repository. None of these attempts have quite managed to reach the >> point where >> they were ready for other OpenStack projects to depend on the library. >> >> This proposal marks the beginning of yet another attempt. The idea is >> to create >> a new openstack-common repository, seed it with Jason Kölker's >> excellent >> infrastructure from his repository[1] and begin importing individual >> APIs while applying the principles above during the review process for >> each proposed API. >> >> [1] - https://github.com/jkoelker/openstack-common >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp