Re: [openstack-dev] How to stage client major releases in Gerrit?
Mark Washenberger wrote: FWIW, I don't think the changes glanceclient needs in v1 will break the 'B' case above. But it does raise a question--if they did, would it be sufficient to backport a change to adapt old supported stable B versions of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is okay. I'm not sure I follow all the pronouns. Could you re-state this again, I think I know what you're asking, but I'd like to be sure. Sorry for being so vague. I'll try to be specific. Branch nova/stable/folsom depends on python-glanceclient/master. Suppose we find that nova/stable/folsom testing is broken when we stage (hopefully before merging) the breaking changes that are part of the python-glanceclient v1.0.0 release. Would it be acceptable in this case to have a compatibility patch to nova/stable/folsom? Or will the only option be to modify the python-glanceclient patch to maintain compatibility? I think that would be an acceptable backport, with bonus points if you can make sure it doesn't break old versions of the libs that could still be used with stable/folsom. (That's a theoretical example though, since we don't have a stable/folsom maintained branch anymore). -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Fri, Nov 22, 2013 at 6:28 PM, Monty Taylor mord...@inaugust.com wrote: On 11/22/2013 06:55 PM, Mark Washenberger wrote: On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins robe...@robertcollins.net mailto:robe...@robertcollins.net wrote: On 22 November 2013 22:31, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. Huh. There are two different directions we use the client in. Client install - cloud API (of arbitrary version A) Server install (of arbitrary version B) using the Python library - cloud API (version B) From a gating perspective I think we want to check that: - we can use the client against some set of cloud versions A - that some set of version B where servers running cloud version B can use the client against cloud version B But today we don't test against ancient versions of A or B. If we were to add tests for such scenarios, I'd strongly argue that we only add then for case A. Where we are using the client lib in an installed cloud, we don't need to test that it can still be used against pre-diablo etc: such installed clouds can keep using the old client lib. I'm afraid that if a critical bug is found in the old client lib, the current path for fixing it is to ask people to update to the latest client version, even internally to their old cloud. So would that cause a branch for backporting fixes? The plan is that the current client libs should always be installable. So we would not (and never have) make a branch for backporting fixes. Yes. I think wires are a bit crossed here, but you and I agree. It seemed to me that Robert was suggesting that old clouds can internally keep using old versions of client libs. Which seems wrong since we don't do backports, so old clouds using old libs would never get security updates. FWIW, I don't think the changes glanceclient needs in v1 will break the 'B' case above. But it does raise a question--if they did, would it be sufficient to backport a change to adapt old supported stable B versions of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is okay. I'm not sure I follow all the pronouns. Could you re-state this again, I think I know what you're asking, but I'd like to be sure. Sorry for being so vague. I'll try to be specific. Branch nova/stable/folsom depends on python-glanceclient/master. Suppose we find that nova/stable/folsom testing is broken when we stage (hopefully before merging) the breaking changes that are part of the python-glanceclient v1.0.0 release. Would it be acceptable in this case to have a compatibility patch to nova/stable/folsom? Or will the only option be to modify the python-glanceclient patch to maintain compatibility? Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
Mark Washenberger wrote: My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? [...] It sounds like a case where we could use a feature branch. There have been a number of them in the past when people wanted to incrementally work on new features without affecting master, and at first glance (haha) it sounds appropriate here. As a quick sidebar, what does a feature branch entail in today's parlance? It can be created on request by release management members (or infra-core team). I /think/ that by default it would get tested against master in other branches. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez thie...@openstack.orgwrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. I'm curious about the historical circumstance of this requirement -- were the services supported master, minus two releases at the time? We're not testing more than two stable releases against the latest clients in CI today, so I find it odd that we still bother with this claim, without demonstrating that it's true. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 22 November 2013 22:31, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. Huh. There are two different directions we use the client in. Client install - cloud API (of arbitrary version A) Server install (of arbitrary version B) using the Python library - cloud API (version B) From a gating perspective I think we want to check that: - we can use the client against some set of cloud versions A - that some set of version B where servers running cloud version B can use the client against cloud version B But today we don't test against ancient versions of A or B. If we were to add tests for such scenarios, I'd strongly argue that we only add then for case A. Where we are using the client lib in an installed cloud, we don't need to test that it can still be used against pre-diablo etc: such installed clouds can keep using the old client lib. So assuming you agree with that assertion, where do we need a branch here? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins robe...@robertcollins.netwrote: On 22 November 2013 22:31, Thierry Carrez thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. Huh. There are two different directions we use the client in. Client install - cloud API (of arbitrary version A) Server install (of arbitrary version B) using the Python library - cloud API (version B) From a gating perspective I think we want to check that: - we can use the client against some set of cloud versions A - that some set of version B where servers running cloud version B can use the client against cloud version B But today we don't test against ancient versions of A or B. If we were to add tests for such scenarios, I'd strongly argue that we only add then for case A. Where we are using the client lib in an installed cloud, we don't need to test that it can still be used against pre-diablo etc: such installed clouds can keep using the old client lib. I'm afraid that if a critical bug is found in the old client lib, the current path for fixing it is to ask people to update to the latest client version, even internally to their old cloud. So would that cause a branch for backporting fixes? FWIW, I don't think the changes glanceclient needs in v1 will break the 'B' case above. But it does raise a question--if they did, would it be sufficient to backport a change to adapt old supported stable B versions of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is okay. So assuming you agree with that assertion, where do we need a branch here? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Fri, Nov 22, 2013 at 12:03 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2013-11-22 10:34:40 +0100 (+0100), Thierry Carrez wrote: It can be created on request by release management members (or infra-core team). I /think/ that by default it would get tested against master in other branches. More details at... URL: https://wiki.openstack.org/wiki/GerritJenkinsGithub#Merge_Commits Cool. Is this documentation essentially explaining how to keep a feature branch up to date with master? (spoiler warning: carefully use merge commits?) -- Jeremy Stanley ___ 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
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 11/22/2013 06:55 PM, Mark Washenberger wrote: On Fri, Nov 22, 2013 at 1:13 PM, Robert Collins robe...@robertcollins.net mailto:robe...@robertcollins.net wrote: On 22 November 2013 22:31, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. Huh. There are two different directions we use the client in. Client install - cloud API (of arbitrary version A) Server install (of arbitrary version B) using the Python library - cloud API (version B) From a gating perspective I think we want to check that: - we can use the client against some set of cloud versions A - that some set of version B where servers running cloud version B can use the client against cloud version B But today we don't test against ancient versions of A or B. If we were to add tests for such scenarios, I'd strongly argue that we only add then for case A. Where we are using the client lib in an installed cloud, we don't need to test that it can still be used against pre-diablo etc: such installed clouds can keep using the old client lib. I'm afraid that if a critical bug is found in the old client lib, the current path for fixing it is to ask people to update to the latest client version, even internally to their old cloud. So would that cause a branch for backporting fixes? The plan is that the current client libs should always be installable. So we would not (and never have) make a branch for backporting fixes. FWIW, I don't think the changes glanceclient needs in v1 will break the 'B' case above. But it does raise a question--if they did, would it be sufficient to backport a change to adapt old supported stable B versions of, say, Nova, to work with the v1 client? Honestly asking, a big ol' NO is okay. I'm not sure I follow all the pronouns. Could you re-state this again, I think I know what you're asking, but I'd like to be sure. So assuming you agree with that assertion, where do we need a branch here? -Rob -- Robert Collins rbtcoll...@hp.com mailto:rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 11/22/2013 09:57 AM, Dolph Mathews wrote: On Fri, Nov 22, 2013 at 3:31 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Robert Collins wrote: I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. Right -- the trick is what does supported mean in that case. When the client libraries were first established as separate deliverables, they came up with a blanket statement that the latest version could always be used with *any* version of openstack you may have. The idea being, if some public cloud was still stuck in pre-diablo times, you could still use the same library to address both this public cloud and the one which was 2 weeks behind Havana HEAD. I'm curious about the historical circumstance of this requirement -- were the services supported master, minus two releases at the time? We're not testing more than two stable releases against the latest clients in CI today, so I find it odd that we still bother with this claim, without demonstrating that it's true. The design of this comes from an end-user perspective. If Alice wants to use a cloud, Bob, Alice should download the current python-glanceclient library, provide it with her credentials, and it should work, regardless of what version of OpenStack Bob's operator happens to be running. The reason for the above is that any other approach is a TERRIBLE end user experience. (As a person who currently is involved with running a scalable cloud application on two OpenStack clouds that are wildly different versions, I can tell you, needing to install different client library versions to talk to them would be madness. That's about outbound API versions though. That means that master *client must always be able to speak to every extant API version. This question is actually about python API consumption, and when we made the policy, we did discuss that were a breaking change to be made in the Python API, clearly the semver Major version should be bumped. Unfortunately for this conversation, we stopped with Brian Waldon's assertion of the major version bump and did not design a system to handle it. We do not currently have the machinery to handle it. At the very latest, we would need to design a modification to how zuul and devstack-gate construct collections of changesets. That said - we need to think about the questions raised above in terms of support of python API. But, more importantly, we should really think long and hard about breaking the python API, even with a major version bump, because no matter how you do it, it's disruptive to library consumers. -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ 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
Re: [openstack-dev] How to stage client major releases in Gerrit?
Mark Washenberger wrote: [...] In order to mitigate that risk, I think it would make a lot of sense to have a place to stage and carefully consider all the breaking changes we want to make. I also would like to have that place be somewhere in Gerrit so that it fits in with our current submission and review process. But if that place is the 'master' branch and we take a long time, then we can't really release any bug fixes to the v0 series in the meantime. I can think of a few workarounds, but they all seem kinda bad. For example, we could put all the breaking changes together in one commit, or we could do all this prep in github. My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? [...] It sounds like a case where we could use a feature branch. There have been a number of them in the past when people wanted to incrementally work on new features without affecting master, and at first glance (haha) it sounds appropriate here. Infra team, thoughts ? -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 22 November 2013 02:57, Monty Taylor mord...@inaugust.com wrote: This is a really complex one because of the gate. It's not just about the semver major version bump. I agree with earlier sentiment - the way to handle breaking changes is to bump the major version, and on the surface I don't have a problem with us doing that, since there is already a mechanism to deal with that. HOWEVER - it's more complex than that with us, because the client libs are part of our integration. We've already agreed on and have been operating on the assumption that client libs do not break rest api backwards compat. We're 3 seconds away from landing gating tests to ensure this is the case. The reasoning here is that an end user of OpenStack should not need to know what version of OpenStack a vendor is running - the latest python-glanceclient should work with diablo and it should work with icehouse. Nothing in this thread breaks that - I just bring it up because it's one of the overall design points that we'll be rubbing against. I don't understand why branches would be needed here *if* the breaking changes don't impact any supported release of OpenStack. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Thu, Nov 21, 2013 at 1:58 AM, Thierry Carrez thie...@openstack.orgwrote: Mark Washenberger wrote: [...] In order to mitigate that risk, I think it would make a lot of sense to have a place to stage and carefully consider all the breaking changes we want to make. I also would like to have that place be somewhere in Gerrit so that it fits in with our current submission and review process. But if that place is the 'master' branch and we take a long time, then we can't really release any bug fixes to the v0 series in the meantime. I can think of a few workarounds, but they all seem kinda bad. For example, we could put all the breaking changes together in one commit, or we could do all this prep in github. My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? [...] It sounds like a case where we could use a feature branch. There have been a number of them in the past when people wanted to incrementally work on new features without affecting master, and at first glance (haha) it sounds appropriate here. As a quick sidebar, what does a feature branch entail in today's parlance? Infra team, thoughts ? -- Thierry Carrez (ttx) ___ 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
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 11/21/2013 01:58 AM, Thierry Carrez wrote: Mark Washenberger wrote: [...] In order to mitigate that risk, I think it would make a lot of sense to have a place to stage and carefully consider all the breaking changes we want to make. I also would like to have that place be somewhere in Gerrit so that it fits in with our current submission and review process. But if that place is the 'master' branch and we take a long time, then we can't really release any bug fixes to the v0 series in the meantime. I can think of a few workarounds, but they all seem kinda bad. For example, we could put all the breaking changes together in one commit, or we could do all this prep in github. My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? [...] It sounds like a case where we could use a feature branch. There have been a number of them in the past when people wanted to incrementally work on new features without affecting master, and at first glance (haha) it sounds appropriate here. Infra team, thoughts ? Hi! This is a really complex one because of the gate. It's not just about the semver major version bump. I agree with earlier sentiment - the way to handle breaking changes is to bump the major version, and on the surface I don't have a problem with us doing that, since there is already a mechanism to deal with that. HOWEVER - it's more complex than that with us, because the client libs are part of our integration. We've already agreed on and have been operating on the assumption that client libs do not break rest api backwards compat. We're 3 seconds away from landing gating tests to ensure this is the case. The reasoning here is that an end user of OpenStack should not need to know what version of OpenStack a vendor is running - the latest python-glanceclient should work with diablo and it should work with icehouse. Nothing in this thread breaks that - I just bring it up because it's one of the overall design points that we'll be rubbing against. Now, in the gate, without bringing backwards compat into the picture - we test master against master, and stable/havana against stable/havana across all the projects. If a project (like a client lib) doesn't have a stable/havana, we use its master branch - this is how master client lib is tested against stable/grizzly and stable/havana right now. And I don't just mean as an end-user test - I mean that we deploy devstack for stable/grizzly with master python-glanceclient and that's what any of the other projects that need to talk to glance (heat, horizon) uses. We do not pin uses of the client libs in stable branches - because we actually explicitly want to gate on the combination, and we want to be sure that releasing a new version of glanceclient does not break someone's grizzly deployment. With all of that background ... In order to consider a set of changes that would be a major version bump for the client libs, we're going to have to figure out what the testing matrix looks like (as in, what do we _want_ to test with each other) and we're going to have to figure out how to orchestrate that in the logic that prepares sets of branches to be tested with each other in the gate. For dev, there are two approaches - we can make a feature/glanceclient-2.0 branch, and leave master as it is, or we can make a stable/1.0 branch and do the breaking work on master. If we do the stable/1.0 approach, we'd probably have to go pin stable/grizzly and stable/havana at =2.0. Problem is, I don't know how to tell devstack gate that stable/grizzly and stable/havana want glanceclient stable/1.0 Alternately, if we do the feature branch, we can avoid thinking about the stable problem for a minute, but we still gate feature branch patches - so you'd have to figure out how to deal with the fact that the feature branch would be gating against master of the other projects. Why don't we just stop cross-gating on the client libs and have our servers consume releases of our clients? Well, that's because they'd be requesting different versions of them at different times. We need to make sure that the client libs can't land changes that break the server projects BEFORE they release, because otherwise the tag/release/tag/re-release cycle would kill us. In any case, sorry for the novel, this request is PARTICULARLY complex to work through, as backwards incompat client library changes is a thing we explicitly designed the integrated gate to consider would never happen. I understand the request, and like I said, it's not unreasonable on its face - but it's going to take some brain time from the infra team I believe ... and fixing the current race conditions has been priority number one this week... That said - bear with us here - if you can hang on for a bit until we've got some space to properly brainstorm about what the physical possibilities are, we can come back with some suggestions and
[openstack-dev] How to stage client major releases in Gerrit?
Hi folks, The project python-glanceclient is getting close to needing a major release in order to finally remove some long-deprecated features, and to make some minor adjustments that are technically backwards-incompatible. Normally, our release process works great. When we cut a release (say 1.0.0), if we realize it doesn't contain a feature we need, we can just add the feature and release a new minor version (say 1.1.0). However, when it comes to cutting out the fat for a major release, if we find a feature that we failed to remove before releasing 1.0.0, we're basically screwed. We have to keep that feature around until we feel like releasing 2.0.0. In order to mitigate that risk, I think it would make a lot of sense to have a place to stage and carefully consider all the breaking changes we want to make. I also would like to have that place be somewhere in Gerrit so that it fits in with our current submission and review process. But if that place is the 'master' branch and we take a long time, then we can't really release any bug fixes to the v0 series in the meantime. I can think of a few workarounds, but they all seem kinda bad. For example, we could put all the breaking changes together in one commit, or we could do all this prep in github. My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? DISCLAIMER: For the purposes of this discussion, it will be utterly unproductive to discuss the relative merits of backwards-breaking changes. Rather let's assume that all breaking changes that would eventually land in the next major release are necessary and have been properly communicated well in advance. If a given breaking change is *not* proper, well that's the kind of thing I want to catch in gerrit reviews in the staging area! Respectully, markwash ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Wed, 2013-11-20 at 15:17 -0800, Clint Byrum wrote: Excerpts from Mark Washenberger's message of 2013-11-20 10:14:42 -0800: Hi folks, The project python-glanceclient is getting close to needing a major release in order to finally remove some long-deprecated features, and to make some minor adjustments that are technically backwards-incompatible. Normally, our release process works great. When we cut a release (say 1.0.0), if we realize it doesn't contain a feature we need, we can just add the feature and release a new minor version (say 1.1.0). However, when it comes to cutting out the fat for a major release, if we find a feature that we failed to remove before releasing 1.0.0, we're basically screwed. We have to keep that feature around until we feel like releasing 2.0.0. In order to mitigate that risk, I think it would make a lot of sense to have a place to stage and carefully consider all the breaking changes we want to make. I also would like to have that place be somewhere in Gerrit so that it fits in with our current submission and review process. But if that place is the 'master' branch and we take a long time, then we can't really release any bug fixes to the v0 series in the meantime. I can think of a few workarounds, but they all seem kinda bad. For example, we could put all the breaking changes together in one commit, or we could do all this prep in github. My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? DISCLAIMER: For the purposes of this discussion, it will be utterly unproductive to discuss the relative merits of backwards-breaking changes. Rather let's assume that all breaking changes that would eventually land in the next major release are necessary and have been properly communicated well in advance. If a given breaking change is *not* proper, well that's the kind of thing I want to catch in gerrit reviews in the staging area! I understand what you're trying to do with this disclaimer. The message above just _screams_ for this discussion, so why not cut it off at the pass? However, glanceclient being a library, not discussing the fact that you're breaking an established API is like not discussing ice at the north pole. If you want to be able to change interfaces without sending a missile up the tail pipe of every project who depends on your code, call it glanceclient2. That solves all of your stated problems from above. You can still deprecate glanceclient and stop maintaining it after some overlap time. And if users hate glanceclient2, then they can keep glanceclient alive with all of its warts. Sorry, completely disagree with this. This is the point of having a major version number in client libraries, when you need to do backward incompatible changes then you bump the major version. You can continue to develop the 0.x and 1.x series in parallel for some amount of time and that's common. If your application doesn't work with the 1.x series then you modify your requirements to indicate this. If this is going to be a problem in openstack then we need to figure out a way of dealing with it because the client libraries are in general a mess and i know that at least keystone is not far off needing to make backward incompatible changes to start to clean it up. Sorry about your disclaimer :) ___ 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
Re: [openstack-dev] How to stage client major releases in Gerrit?
On Wed, Nov 20, 2013 at 3:17 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Mark Washenberger's message of 2013-11-20 10:14:42 -0800: Hi folks, The project python-glanceclient is getting close to needing a major release in order to finally remove some long-deprecated features, and to make some minor adjustments that are technically backwards-incompatible. Normally, our release process works great. When we cut a release (say 1.0.0), if we realize it doesn't contain a feature we need, we can just add the feature and release a new minor version (say 1.1.0). However, when it comes to cutting out the fat for a major release, if we find a feature that we failed to remove before releasing 1.0.0, we're basically screwed. We have to keep that feature around until we feel like releasing 2.0.0. In order to mitigate that risk, I think it would make a lot of sense to have a place to stage and carefully consider all the breaking changes we want to make. I also would like to have that place be somewhere in Gerrit so that it fits in with our current submission and review process. But if that place is the 'master' branch and we take a long time, then we can't really release any bug fixes to the v0 series in the meantime. I can think of a few workarounds, but they all seem kinda bad. For example, we could put all the breaking changes together in one commit, or we could do all this prep in github. My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? DISCLAIMER: For the purposes of this discussion, it will be utterly unproductive to discuss the relative merits of backwards-breaking changes. Rather let's assume that all breaking changes that would eventually land in the next major release are necessary and have been properly communicated well in advance. If a given breaking change is *not* proper, well that's the kind of thing I want to catch in gerrit reviews in the staging area! I understand what you're trying to do with this disclaimer. The message above just _screams_ for this discussion, so why not cut it off at the pass? However, glanceclient being a library, not discussing the fact that you're breaking an established API is like not discussing ice at the north pole. It is both a CLI and a library. I think different considerations might be more relevant for those different areas. But this point leads to a much larger discussion of what standards we should enforce for major revisions, which we should probably defer for just a moment. I hope the outcome of discussing my main point will be a space where we can flesh out such standards with real world examples. If you want to be able to change interfaces without sending a missile up the tail pipe of every project who depends on your code, call it glanceclient2. That solves all of your stated problems from above. You can still deprecate glanceclient and stop maintaining it after some overlap time. And if users hate glanceclient2, then they can keep glanceclient alive with all of its warts. While I think glanceclient2 is an interesting suggestion for really large, sweeping changes, I don't think we are anywhere near that point. Overall, I think you are unintentionally mischaracterizing the nature of the breaking changes that are being considered--making them seem several orders of magnitude greater and more disruptive than they actually are. For folks who believe that under very well-defined and conservative circumstances it is okay to make a breaking change in a major release, this mischaracterization is going to be really confusing. I guess if we still want to talk about when, if ever, to release a major version of a client, maybe we could take it to another thread? The proposal to disallow major revisions of OpenStack clients under all normal circumstances seems like great TC fodder in any case, especially now that I'm only a spectator. 3, markwash ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 21 November 2013 07:14, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks, The project python-glanceclient is getting close to needing a major release in order to finally remove some long-deprecated features, and to make some minor adjustments that are technically backwards-incompatible. Normally, our release process works great. When we cut a release (say 1.0.0), if we realize it doesn't contain a feature we need, we can just add the feature and release a new minor version (say 1.1.0). However, when it comes to cutting out the fat for a major release, if we find a feature that we failed to remove before releasing 1.0.0, we're basically screwed. We have to keep that feature around until we feel like releasing 2.0.0. In order to mitigate that risk, I think it would make a lot of sense to have a place to stage and carefully consider all the breaking changes we want to make. I also would like to have that place be somewhere in Gerrit so that it fits in with our current submission and review process. But if that place is the 'master' branch and we take a long time, then we can't really release any bug fixes to the v0 series in the meantime. I can think of a few workarounds, but they all seem kinda bad. For example, we could put all the breaking changes together in one commit, or we could do all this prep in github. My question is, is there a correct way to stage breaking changes in Gerrit? Has some other team already dealt with this problem? Why not just propose them to Gerrit? Get a set of reviews +2 +2 but not APRV, and once you're satisfied you have everything, approve them then release. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to stage client major releases in Gerrit?
On 21 November 2013 12:17, Clint Byrum cl...@fewbar.com wrote: Excerpts from Mark Washenberger's message of 2013-11-20 10:14:42 -0800: I understand what you're trying to do with this disclaimer. The message above just _screams_ for this discussion, so why not cut it off at the pass? However, glanceclient being a library, not discussing the fact that you're breaking an established API is like not discussing ice at the north pole. Semver provides for doing breaking changes. And thats whats happening here: things that have been deprecated for extended periods are finally being cleaned up. Anyone using those features is already getting deprecation warnings... totally fine for that cleanup to be done. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
