What happened to v1.2.8?

[dombarnes]

This was a dependency in my project last week, and now its gone from the public rubygems database, breaking clean installs.

[nahi]

@hsbt ?

[AlanFoster]

Just bumped into this with our CI builds now all failing:

Your bundle is locked to logger (1.2.8), but that version could not be found in
any of the sources listed in your Gemfile. If you haven't changed sources, that
means the author of logger (1.2.8) has removed it. You'll need to update your
bundle to a different version of logger (1.2.8) that hasn't been removed in
order to install.

I can't immediately see why it would have been yanked, but the Gem version history is a bit weird:

[seanhussey]

I put together some info on the issue here: https://stackoverflow.com/questions/53625347/what-happened-to-version-1-2-8-of-the-logger-gem

The newly published 1.2.7 has changes that are not present in this repo. When 1.2.7 was published in this repo (2008), it had not yet been gemified (that happened in 2011 for version 1.2.8). None of the forks on GitHub contain this new code.

So I'm curious as to where this new code is coming from. Is there a new official repo? Why drop down the version number? Why was 1.2.8 yanked?

[hsbt]

I yanked v1.2.8 because the current version of logger on the ruby standard library is 1.2.7.

[hsbt]

This is the new canonical repository https://github.com/ruby/logger

[hsbt]

I released v1.3.0 that is the same code of v1.2.7. Please use it instead of v1.2.8.

[sent-hil]

Same issue as @AlanFoster. Unfortunate a published version was yanked after 7 years.

[jrochkind]

I yanked v1.2.8 because the current version of logger on the ruby standard library is 1.2.7.

I don't understand why this was a reason to yank 1.2.8? Lots of projects were using it. There is no problem with a version existing on rubygems that is beyond what is in the ruby standard lib. Just like the 1.3.0 you went on to release.

I'm guessing you decided it was a mistake that you released 1.2.8 at all, but only realized that after 7 years? It was very disruptive to yank it at this point. Working apps now have to be changed just in order to keep working exactly how they were before, which always involves some risk and developer attention.

It also seemed so odd that it made me suspect some kind of malicious activity, since there have been recent npm (not ruby) malicious attacks that involved yanking and releasing in odd patterns.

I think this was a mistake to yank a gem people had been using for 7 years, with the reason that it had never been included in stdlib -- this does not seem like a reason to inconvenience people by yanking.

[Xylakant]

The 1.3.0 and 1.2.7 are not the same code as the yanked 1.2.8. Most notably, they are both not compatible with ruby 1.8.x which is still the default install on RHEL 6.x systems.

I'm absolutely in favour of not supporting 1.8.x in newer versions of libraries, but yanking a perfectly working version and breaking existing and deployed code is not a great move.

[chechsp]

1.2.7 is not the same as 1.2.8 (this is obvious), and it does not work where 1.2.8 worked. I just created a blank project based on other working projects with a gem that has a dependency on logger, and it doesn't even start. Errors are:

SyntaxError: /usr/local/rvm/gems/ruby-2.2.0@my-gemset/gems/logger-1.2.7/lib/logger.rb:482: syntax error, unexpected '.'
    @logdev&.write(msg)
             ^
/usr/local/rvm/gems/ruby-2.2.0@my-gemset/gems/logger-1.2.7/lib/logger.rb:569: syntax error, unexpected '.'
    @logdev&.close

Looks by comparing code side by side that 1.2.8 had no ampersands and an if @logdev after the close call.

EDIT: 1.3.0 doesn't work either.

[jrochkind]

While I would appreciate some feedback from @nahi and @hsbt , my guess as to what's going on is -- there was no reason for there to be a logger rubygem at all -- logger is in ruby stdlib. And no reason for anything to declare an explicit dependendency on a logger gem.

So, @chechsp, one solution might be removing the dependency on logger. And then everything might just work, as logger is in stdlib and doesn't need to be declared as a dependency.

I realize this isn't always possible/easy, if the dependency an indirect dependendency (dependency of one of your dependencies) in the first place. Also it might not solve your problem.

I believe it was a mistake to yank it, and it is disruptive not to have it available, and apparently not to have equivalent code available as a different version either. A rubygems blog post from 2015 says:

However, we’ve been using an Amazon S3 bucket to store the gems for years now with versioning on - so if someone does remove gems that are necessary, we can easily restore them. We hope it won’t ever be.

I'm not sure if they've ever done that, but @hsbt , this might be a case where it is worth looking into if the exact source that was previously 1.2.8 can be restored by rubygems, so you can put it back as either 1.2.8 or another version. Having the 1.2.8 source would also allow someone to see if 1.2.8 really is identical to 1.3.0 -- you said it was intended to be, but others above have found that it is not. We have no easy way to verify without 1.2.8 being available.

[Xylakant]

@jrochkind Removing the logger gem from a gemspec or a Gemfile is a fix, since logger is indeed part of the stdlib. Yanking 1.2.8 still breaks builds left and right where people mistakenly added the dependency, thinking they'd need it. Even releasing 1.2.9 with the same code would still break that build in cases where the version is pinned. The only way to restore the working state would be to un-yank 1.2.8.
I have the source of 1.2.8 available, so I can assure you that 1.2.8 is ruby 1.8 compatible and 1.3 and 1.2.7 both use 1.9 array syntax, so they're definitely not the same.

[chechsp]

So, @chechsp, one solution might be removing the dependency on logger. And then everything might just work, as logger is in stdlib and doesn't need to be declared as a dependency.

I realize this isn't always possible/easy, if the dependency an indirect dependendency (dependency of one of your dependencies) in the first place. Also it might not solve your problem.

@jrochkind Removing the logger gem from a gemspec or a Gemfile is a fix, since logger is indeed part of the stdlib. Yanking 1.2.8 still breaks builds left and right where people mistakenly added the dependency, thinking they'd need it.

Thanks for your comments, I did solve my issue manually installing a copy of 1.2.8 replacing the 1.2.7 code, but I unfortunately have no control over the gem that has the dependency (carrierwave_encrypter_decrypter). I'll try to ask the developer to remove the logger dependency or make a pull request when I have some time, I'd like to test it before asking anything. I just wanted to point out that this change is breaking live projects right now.

Logger 1.2.8 is going to end up being a unicorn, but a needed one :P we unfortunately still use 1.8.7 and from other comments it seems like that one is screwed too.

EDIT: typo

[zuzannast]

We're using a gem that has a dependency on this one and we were using the 1.2.8 version. The builds started failing breaks for us as well and after updating gem to v. 1.3.0, we receive the same errors as @chechsp described (our ruby version is 2.2.3). So, what should I do in order to make the new released version working?

I know that I could submit a PR to remove this dependency from one of our gems, but I'd expect a proper guide to upgrade the version as it's previous one is now removed completely.

[chechsp]

We're using a gem that has a dependency on this one and we were using the 1.2.8 version. The builds started failing breaks for us as well and after updating gem to v. 1.3.0, we receive the same errors as @chechsp described. So, what should I do in order to make the new released version working?

For me it's failing in ruby 2.2.0, which should in my opinion be supported, and we use 1.8.7 too (unfortunately). I have no time right now to deal with PRs through multiple gems and ruby versions, so I forked this project and uploaded the 1.2.8 code (I didn't see any wrongdoing reading the license). This is a bad solution but the quickest alternative. You will not be able to add it as a dependency on an engine since you can't specify the git repo you want to use, but you can add it in your gemfile like this:

gem 'logger', git: 'https://github.com/chechsp/logger.git', branch: '1.2.8'

I hope this issue gets solved in its official repo, but meanwhile we need to keep going.

Note: I created an empty project to show how logger 1.3.0 fails, just clone, bundle and rails s using the specified ruby version.

[mnuic]

Just bumped on this.

We have some old legacy applications on old ruby 1.8/1.9. that were depending on logger v1.2.8. Tried using logger v1.2.7/v1.3.0 with ruby 1.9./2.2/2.3 but it all fails.

For a workaround, I run one of older docker images that have logger v1.2.8 and copy it to application repo and install it with:
gem install --local logger-1.2.8.gem

And now it works.
So if anyone needs a logger gem, I am attaching it here.

logger-1.2.8.gem.gz

[hsbt]

I wonder why people use logger-1.2.8 with Ruby 1.8/1.9 with Gemfile. You can use logger library without Gemfile on Ruby 1.8 and 1.9.

[Xylakant]

@hsbt because someone in a gem that you depend on (mistakenly) added it as a dependency for example. For example like https://github.com/kanet77/togglv8 did. Or because someone did mistakenly add it as a direct dependency, having seen it somewhere else.

The code would work perfectly without using logger as a gem, but since it's there, builds now break that didn't break before. In the case where the dependency is in your own Gemfile, fixing it is simple: remove the entry. In cases where you inherit logger as a transitive dependency the fix is substantially more difficult. It requires a fixed version of the dependency that depends on logger, something that may be hard to obtain on unmaintained deps.

[hsbt]

I see. I agreed with your opinion.

Note: logger-1.2.8 is NOT part of stdlib from the first release. Please use at your own risk

[josh-levinson]

For those still reliant on a specific version of logger, you can also use the 1.2.8 release tag on the project to add it to your Gemfile, which will then update from the old Git release. I don't know if this is better or worse than forking it, but this was the official release.

gem 'logger', :git => 'https://github.com/nahi/logger.git', :tag => 'RELEASE_1_2_8'

[jrochkind]

@hsbt and @nahi , would you consider restoring 1.2.8 to rubygems? May require asking for support from rubygems to do, but should hypothetically be possible.

[hsbt]

I have no motivation and responsibility to support it. Because it's not the official release of the ruby language.

[nahi]

@hsbt You don't care if I upload 1.2.8 to rubygems.org again? Though I need to find a way to build 1.2.8, though.

[hsbt]

You don't care if I upload 1.2.8 to rubygems.org again?

Yes. And we can not restore logger-1.2.8 because we have no way to restore yanked gem on rubygems.org.

But If you picked the same commit of logger-1.2.8 from https://github.com/ruby/logger, I can push its commit as logger-1.2.9 and yank logger-1.2.7.

How about this plan?

[nahi]

Oh I didn't know we can't restore the yanked gem. Hmm.

I think I should create 1.2.8.1, though we can't solve a package that specifies 1.2.8 directly, though.

[nahi]

How about this plan?

What problem does it solve?

Please don't yank gem any more. Yanking 1.2.8 was unexpected incident for me.

[hsbt]

What problem does it solve?

We can use ruby/logger as the canonical repository and resolve this dependency problem after bundle update logger with the old ruby.

Also, I can ship logger-1.2.8.1 and logger-1.2.7.1 from ruby/logger@3a74553.

Please don't yank gem any more. Yanking 1.2.8 was unexpected incident for me.

Unfortunately, logger-1.2.7 is shipped from Ruby 2.6.0. We need to yank logger-1.2.7 when it was shipped 1.2.8.1 and 1.2.7.1. We should keep consistency for support version of Ruby by version order.

[jrochkind]

Yes, the yanking of 1.2.8 has caused a problem for people with old legacy projects that depend on it. Those projects can no longer be installed on new machine without changes, none of the other versions available seem to be identical, so additional changes are required -- and these are old legacy projects which probably aren't getting much maintenance. It was disruptive, and I don't think there was a reason it was needed?

I think maybe you can restore 1.2.8 with assistance from rubygems team. In the blog post from rubygems when they made yank permanent, they said:

A concern of ours about gem yank and its behavior was that someone could maliciously or accidentally remove gems that others depended on. However, we’ve been using an Amazon S3 bucket to store the gems for years now with versioning on - so if someone does remove gems that are necessary, we can easily restore them. We hope it won’t ever be.

So I think it's worth contacting rubygems team to see if they can restore 1.2.8, if that is desired/acceptable to gem owners, and we don't know of any problems a restore would cause. They may prefer restoring it from their version backup, to ensure that what gets restored is exactly what was there before, which is required, as rubygems versions need to be immutable.

I can try to contact them for you if you would like me to, and you authorize restoring the yank.

[hsbt]

I'm also a core member of the RubyGems team includes rubygems.org.

we don't know of any problems a restore would cause.

I'm against to restore the old assets of logger-1.2.8. Because It's not the official release of logger library. logger gem is promoted the official gem now. We need to avoid to includes un-official gems.

[jrochkind]

Logger 1.2.8 had been released for over 7 years. I do not understand why it was yanked. It may be that it was a mistake to release it in the first place? After 7 years, it is very disruptive to correct this mistake by yanking it. You are adding maintenance burden to projects that were dependent on the mistaken release.

Things that are not supported exist in rubygems all the time. All sorts of things that have been end-of-lifed are in rubygems. We do not yank gems when they become unsupported, because it would cause a huge disruption to do so. All sorts of "un-official gems" are in rubygems.

I am very disappointed in this decision, because I still do not understand it, or understand what justifies creating this added headache. It lowers my trust in the stewardship of the ruby ecosystem, to create this seemingly unnecessary headache.

For those running into this problem, the workaround I can think of, is if someone believes they have access to (or a way to recreate) the exact gem package for 1.2.8, you can create a new gem and push that gem package to it. Perhaps call it something like logger_legacy_workaround. And then change your apps to depend on that gem instead?

If I understand what was going on (and I'm not sure I do!), no project should have been dependent on logger 1.2.8 ever, it was a mistaken release (and I don't really understand why a project would declare a rubygems dependency on logger when it's in stdlib in the first place, that may have been a mistake too?). But the mistake happened (and wasn't caught for 7 years?), and the apps were working despite the mistake, and there should be a way to keep them working as they were.

[hsbt]

I pushed logger-1.2.7.1 from ruby/logger@5d9c5e7

It works with Ruby 1.8 and 1.9.

[nahi]

What problem does it solve?

We can use ruby/logger as the canonical repository and resolve this dependency problem after bundle update logger with the old ruby.

"resolve this dependency problem after bundle update logger with the old ruby" I don't get your point. Could you elaborate?

Also, it seems you released 1.2.7.1 and yanked 1.2.7. What problem does it solve?

[chechsp]

A gemfile locked at 1.2.8 isn't going to update to 1.2.7.1.

De-yanking or uploading 1.2.8.1 was a decent solution.

More yanks = more harm.

[kbowley-asu]

I would just like to add another "me too" to the list of people who were bitten by this really poor decision. No matter what personal convictions led @hsbt to yank version 1.2.8, his pride should be swallowed and de-yank the gem.

[hsbt]

I also pushed logger-1.2.8.1 from ruby/logger@3bfbbac. It was same as 1.2.8 without the version number. This is my final action for this issue.

In historical reason. rubygems.org blocked to update the same namespace like logger, fileutils, etc from rubygems/rubygems.org#1155 . So nahi was lost ownership of logger by its time.

I'm working Gemfication project targeted Ruby 3.0 now. I'm going to release the official gems extracted from Ruby core repository with rubygems/rubygems.org#1775 every year.

So, It's the most important things. We need to avoid the un-official gems that were released before rubygems/rubygems.org#1155. For example, fileutils-0.7 that was released at 2011 is a completely different library with the stdlib of Ruby. When you install It, It broke your environment. I have a responsibility to maintain the current stdlibs in ruby core repository.

I'm sorry to your inconvenience experience. Please update your dependency of the project to logger-1.2.7.1 or 1.2.8.1. They are working with Ruby 1.8 to 2.3.