Withdraw 4.4.0
mfischer-zd opened this issue · 24 comments
Ridley made a backward-incompatible change in 4.4.0, removing an API method. It should be withdrawn and replaced with Ridley 5.0. See berkshelf/berkshelf#1495
Move the conversation to here from berkshelf/berkshelf#1495
/cc @jkeiser
Being bitten by this as well
do we just need to add method_missing handling to translate methods to hash lookups?
I recommend you withdraw this release first to help mitigate user impact.
Then you can concentrate on a fix.
On Monday, January 11, 2016, Lamont Granquist notifications@github.com
wrote:
do we just need to add method_missing handling to translate methods to
hash lookups?—
Reply to this email directly or view it on GitHub
#330 (comment).
Yup just got bitten by this. All of a sudden CI started failing and I thought I was going crazy.
👍
It might be a good idea to have some specs for Ridley::Chef::Configso the build will fail when its API is broken.
+1
In the meantime pinning to ridley version v4.3.2 resolves issues related to not being able to call methods removed in #325. In my case Ridley::Chef::Config#chef_server_url started failing several CI builds for me.
This is bombing our chefspec CI tests as well. +1 for a rollback.
Working on it! Will get a 4.4.1 without the proxy stuff, and get proper tests in and remerge when it works. Sorry!
I appreciate that you're working on a 4.4.1 release @jkeiser, but in the interim, please remove 4.4.0 from the Rubygems servers so as not to further interrupt people's work.
can you yank 4.4.0 in the interim? gem yank ridley -v 4.4.0
This is fixed: #331
We're trying not to yank things, it causes angst, the quick revert and release is intended to have the same effect.
Do respond or create more bugs if you are still having issues though!
There is far less angst to your customers for yanking buggy Gems than dealing with surprising failures. By yanking them, you contain the damage window while you work on a fix.
We're trying not to yank things, it causes angst — @jkeiser
👍 Glad you decided not to.
There is far less angst to your customers for yanking buggy Gems than dealing with surprising failures. By yanking them, you contain the damage window while you work on a fix.
@mfischer-zd I disagree, CI in many of the above users cases caused their build to fail. Yanking could potentially require manual intervention to correct the build. Resolving this in the users gemfile/gemspec when the bad version existed was sufficient, in my opinion at least. Reverting and submitting a patch version that all of the above people would have pulled automatically resolves this issue for them and customers who would've pulled it later in the day.
@erran-r7 I think it depends on whether or not you're automatically running bundle update at every CI run. We're not, as there's nothing to be gained by doing so when performing CI with Chef cookbooks. Our bundles are locked and only modified when someone has cause to do so.
I imagine, or at least hope, that most users manage their cookbooks the same way.
@mfischer-zd I totally agree that we are responsible for clearing the broken release as quickly as possible, and we flubbed that (I wasn't checking mail last night and we didn't declare an incident). Sorry.
It's not necessary to yank, however, since a revert and re-release only costs us a few more minutes and gives the same effect. The issue with time here was how long it took me to get started.
As for corrective action, I will be adding a run of the berkshelf master tests to catch this and any related regressions from happening in the future. It will turn super red before we ever release.
@jkeiser in this case the damage window was small, so thank you for the quick action. However I would always yank first, fix later, in the case of severely buggy Gems. There's no question that yanking will inconvenience some people who have already put the buggy version in their bundles, but I still contend that it will inconvenience fewer people overall.
If the Gem is no longer available, that gives me a very strong hint that I need to revert. On the other hand, if things break with the new Gem, I then have to figure out the root cause, which could take significantly longer to determine -- your changes are mixed in with mine and I have to isolate the cause.
And as you know, Ruby error messages are not always clear. :)
thanks @jkeiser for your explaination.
FYI, I just re-released this with the relevant fixes in 4.4.2. Let me know if you see any issues; the berkshelf tests are working fine against it (really this time :). I'll watch the issue!
❤️