<p dir="ltr"><br>
On Mar 4, 2016 10:16, "Monty Taylor" <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
><br>
> On 03/04/2016 08:37 AM, Ruby Loo wrote:<br>
>><br>
>> Hijacked from ' [openstack-dev] [ironic] Remember to follow RFE process'<br>
>> thread:<br>
>><br>
>>         > Should we revert the patch [1] for now? (Disclaimer. I haven't looked at the<br>
>>         > patch itself. But I don't think I should have to, to know what the API<br>
>>         > change is.)<br>
>>         ><br>
>><br>
>>         Thanks for calling it out Ruby, that's unfortunate that the<br>
>>         patch was<br>
>>         merged without the RFE being approved. About reverting the patch I<br>
>>         think we shouldn't do that now because the patch is touching the API<br>
>>         and introducing a new microversion to it.<br>
>><br>
>><br>
>>     Exactly. I've -2'ed the revert, as removing API version is even<br>
>>     worse than landing a change without an RFE approved. Let us make<br>
>>     sure to approve RFE asap, and then adjust the code according to it.<br>
>><br>
>><br>
>> This brings up another issue, which I recall discussing before. Did we<br>
>> decide that we'd never revert something that touches the<br>
>> API/microversion? It might be good to have guidelines on this if we<br>
>> don't already. IF the API is incorrect? If the API could be improved? If<br>
>> the API was only in master for eg 48 hours?<br>
><br>
><br>
> I believe you need to treat master as if it's deployed to production. So once an API change is released, 'fixing' it needs to be done like any other API change - with a microversion bump and appropriate backwards compat.<br>
><br>
> (For instance, I have a CI/CD pipeline merging from master every hour and doing a deploy - so 48 hours is a long time ago)<br>
><br>
> Monty<br></p>
<p dir="ltr">So let me jump in here and add in that a direct revert only should happen in extreme circumstances: aka a change that breaks behavior without a micro version bump - or something that is causing a break that cannot be fixed easily rolling forward. (Unable to land code in the gate at all for example, including roll forward fixes)</p>
<p dir="ltr">In general (and especially with microversions) fail and fix moving forward is much better for the end users/deployers especially since folks are doing CD more aggressively now.</p>
<p dir="ltr">There are other considerations but a revert really is one of the most extreme responses and should be used sparingly. </p>
<p dir="ltr">--Morgan</p>