Release a new patch version of Rack 1.4 with good release number #322

Closed
nicolasblanco opened this Issue Jan 20, 2012 · 25 comments

Comments

Projects
None yet

The latest released version of Rack (1.4.0) has a bad version number which was fixed a few days after its release here :

e20baec

Now, Rails 3.2 has been released (which depends on rack ~> 1.4.0) and the latest stable version of Omniauth depends on a good Rack.release number as you can see in this commit :
omniauth/omniauth@21739ee

So, please release quickly a new patch version of Rack with a good release number ❤️

Yes I found this bug and need use omniauth and rack master branch not stable version.

+1 to fix it.

Contributor

sferik commented Jan 20, 2012

After you release 1.4.1, please yank 1.4.0.

Please don't yank 1.4.0. There's no point in breaking deploys for everyone else.

asanghi commented Jan 21, 2012

The workaround until rack release number is fixed is to explicitly use the git repo in the Gemfile, (if you're paranoid about head, then point to the ref containing the good release number)!

+1 please release soon!

svoop commented Jan 21, 2012

@asangi:
At least on my box it's not quite that simple. To make this work, both the faulty rack-1.4 from RubyGems and the fixed revision from Github must be installed. So this in the Gemfile ist not enough:

gem 'inploy', git: 'git://github.com/dcrec1/inploy.git', ref: 'ca020759cd'

You have to do a "gem install rack" before or after the "bundle install" as well.

Owner

raggi commented Jan 22, 2012

DO NOT +1 RACK TICKETS.

@raggi raggi closed this Jan 22, 2012

@raggi +1 ❤️ ❤️ ❤️ ❤️ ❤️

mdi commented Jan 22, 2012

@raggi I noticed you deleted several of the comments on this ticket including ones that weren't just a "+1". Also noticed you're calling users of this library "assholes". Nice form, buddy.

And if I'm not mistaken, you can turn notifications off on individual tickets. See that link at the bottom of the page?

Owner

raggi commented Jan 22, 2012

@mdi what you're missing, is that by coming and plastering tickets with +1s, that's basically saying "we feel that we must vote on this because the maintainer isn't going to be believe us it's important", which in other words says that you guys all think I am so retarded as to not realize that people use omniauth, and/or you fail to realize that over the last few months that i've been largely on my own maintaining this library, that I have address every single issue created.

Contributor

sferik commented Jan 22, 2012

@raggi the fact that you are the only maintainer of rack is a problem of your own making. There have been multiple requests from others to help maintain rack, all of which have been ignored.

This version of rack worked for me.

gem "rack", git: "https://github.com/rack/rack.git", ref: "e20baec005238f9876281c0d083fe5a4e01aa034" 

I found the specific tag in another issue that I can't find at the moment.

Owner

raggi commented Jan 23, 2012

@sferik I've added a few maintainers recently actually. When I get working patches from folks regularly that don't need coercion or break common use cases, I'll open up commit. It turns out that it's actually very hard to write stable patches for software used by so many people. I know you want commit, but I'm not going to give that to you when you're throwing out comments like After you release 1.4.1, please yank 1.4.0.

I agree this use case is important, and I'm trying to get 1.4.1 out asap, but a lot of folks I've been waiting on for confirmations of other equally important bugs prior to release are hard to contact outside of work hours. I don't have any time during the week to deal with this.

Owner

raggi commented Jan 23, 2012

@sferik being absolutely explicit, i'm afraid this doesn't count: https://github.com/rack/rack/commits/master?author=sferik

Owner

raggi commented Jan 23, 2012

And before someone quotes the rubinius commit policy pretending that's the way to go, I'd like to remind you all of a few factors:

  • rubinius has multiple PAID full time maintainers that watch over the code base
  • rubinius has a commit and change rate of often 10+ commits a day
  • rubinius has a more linear release process at this point in time (not 3 active branches with quite different dependencies and major changes between them)

So I'd love to do that, but that's going to require people to be a lot more proactive, and requests for beta tests / integration tests to happen in less than a month (frequent time for response from various major community users, despite direct in person contact, and that's if it even happens. People included on that list are @rkh @tenderlove @chneukirchen @manveru all of which have commit themselves also).

I hope this makes things a little more clear. Frankly, the experience I get is that no one cares until /after release/, which is ok, but, if you don't want to provide good patches, or test releases, or anything else, then don't expect a good response when you're trying to force a release out of someone for just one of several concurrent problems that are in the process of being fixed.

danchoi commented Jan 23, 2012

Where did the original 'assholes' comment go? I treasure it!

Owner

chneukirchen commented Jan 23, 2012

Please keep the discussion civil. Thanks.

Contributor

sferik commented Jan 24, 2012

Thanks for releasing 1.4.1.

Can you please explain what's wrong with my suggestion to yank 1.4.0 now that 1.4.1 has been released? How would it break deploys?

Owner

raggi commented Jan 24, 2012

@sferik not everyone is an omniauth user. some people are using 1.4.0 without any issues, and there's no reason to break it for them.

@sferik,

When you yank a gem, it can't be installed via bundler any longer. You have to run your own gem server with a copy of the yanked gem. Yanked gem files are still stored on RubyGems, but they're not available in the gem index. So, for everyone that's not using OmniAuth, you would break their deploys because they couldn't fetch the gem any longer. For those using omniauth, you have to upgrade anyway, so there's nothing to be gained by yanking. In short, never yank a gem unless it's 100% necessary (e.g., it does something like "rm -rf /").

Contributor

sferik commented Jan 24, 2012

Ah, I was under the impression that yanked gems could still be install as dependencies, but this makes sense given bundler's reliance on the index.

I updated to 1.4.1, and am still experiencing the same issue (same stack trace as well). Any ideas? Is this still broken?

@ghost

ghost commented Apr 17, 2012

I am having same problem. I have rack 1.4.1 and omniauth 0.2.6. any fix will be greatly appreciated

@ajitscorpio : your omniauth version is way too old, update to 1.1

@ghost

ghost commented Apr 17, 2012

@slainer68: i updated to 1.1 and it worked. thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment