The logger gem, which has been at version 1.2.8 for 7.5 years, was yanked from rubygems.org today and replaced with version 1.2.7:
https://rubygems.org/gems/logger/versions/1.2.8
This library was not a gem before 1.2.8. The gemspec was added on 2011-05-11:
https://github.com/nahi/logger/commit/af96ca8fbf9ca1a20812a222c27d5c1ccf5d297e
There has never been an official release of a 1.2.7 version, as told by the release history on GitHub:
https://github.com/nahi/logger/releases
There have been no commits to this repo for more than 6 years. If a 1.2.7 version of the library was built as a gem, it was done so from a different source repo. I see no evidence that the nahi repo has been superseded by any other repo.
Does anyone know what happened? At this point, we're going to set the source for this gem to the 1.2.8 release commit on GitHub until there's some official word on this.
EDIT: My question isn't about whether or not the logger gem still needs to be maintained. If that were the case, why publish a new version yesterday? And why go backwards in version numbering? And why is there no record of these changes in the repo? There are big differences in what was marked (but not released) as 1.2.7 back in 2008 (and remember, 1.2.8 was published as a gem for the first time 3 years after that in 2011) and what was published yesterday as 1.2.7. We rely on a gem that requires this gem. Sure, we'll reevaluate whether or not that requirement is still true, but the circumstances around yanking 1.2.8 and replacing it with something that has no (established or announced) record of change is odd.
I just saw this too as I'm doing a clean deploy to my web host. I've raised an issue on the github repo https://github.com/nahi/logger/issues/3
Related
I was browsing rubygems.org for themes in Jekyll and they were causing trouble with the current versions of jekyll.
Like here I was trying out linaro-jekyll-theme. and I got this
Fetching gem metadata from https://rubygems.org/.........
Resolving dependencies....
Bundler could not find compatible versions for gem "jekyll":
In Gemfile:
jekyll (~> 4.2.1)
linaro-jekyll-theme was resolved to 1.0, which depends on
jekyll (~> 3.4)
Bundler could not find compatible versions for gem "linaro-jekyll-theme":
In snapshot (Gemfile.lock):
linaro-jekyll-theme (= 1.0)
In Gemfile:
linaro-jekyll-theme
Running bundle update will rebuild your snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
How to change jekyll versions according to the needs. Is there any problem associated with changing versions so many times?
A Jekyll theme (or any gem in general) might depend on a certain version of another gem because
is depends on certain features that were removed or changed in later versions or
the author just pinned the version as a reminder to check compatibility when a new major version is released because major releases might break the gem.
In this example, the author might already have known that their gem works with Jekyll 3.x but not with 4.x anymore or they just wanted to revisit the theme later if it still works with Jekyll 4.x but never did.
Changing versions is not really a problem and because of bundler you can do that easily and as often as you want or need to. But there might be a general issue with downgrading a gem. Newer versions are released mainly for two reasons:
to add new features and
to fix bugs and security vulnerabilities.
When you work with an older version of a gem then you might miss new features that might be okay if you do not need them. But you also might open yourself to security vulnerabilities that have already been fixed in later versions.
My advice is:
Try using the latest version of a gem whenever possible.
If another gem depends on an older version and you, therefore, an update to the latest version, then I would ask myself if it is really worth it to use such an outdated gem. When the gem hasn't been updated to depend on the latest version for a longer period of time then it is likely that it will not be updated anymore which is a risk.
If you still want or need to downgrade then I suggest checking the changelog of the gem what features and bug fixes you will miss. And to check the changelog on a regular basis in the future too.
Useful links in this context: The list of Jekyll versions, as you can see Jekyll 3.4 is about five years old that is a lot of time to build new features, fix bugs and security vulnerabilities. And a lot of time for a theme author to make a theme compatible with newer versions. And the Jekyll Changelog in which you can check what you would be missing when you downgrade to 3.4 instead of using the latest version (currently 4.2.1). And that list is very long.
I am working on a server migration and upgrade, and I don't code in Ruby at all.
Is there an easy way for me to scan / review the gemfile / installed dependencies to check that latest updated / unpatched dependencies?
The code references to a hundred at least dependencies and I am not sure which are no longer the latest stable version.
You can try bundle with the outdated command and using the --strict parameter to make sure it lists only compatible gems:
bundle outdated --strict
But like I said in my comment above, you usually want to know what you are doing if you plan to upgrade any gem. Any changes to the API or functionality of a gem may break part of or the entire codebase. Make sure you have working backups.
This is what I am talking about.
My attempt is to repush the exact same version, 0.1.12.
My previous push is invalid, it broken gem what I push.
I highly want to publish this version, like I already implement the sem-versioning.
the pushing process yield:
Repushing of gem versions is not allowed. Please use a new version and retry
So is it possible? if not what is the main use of yanking a submitted gem?
Nope, you can not re-submit the same version number, this is made on purpose for security reasons, avoiding maintainers to upload the same version without getting noticed by the developers. So you will need to release a new version of your gem
Isn't the Gemfile.lock a hack used to perpetuate bad practices in dependency version control?
I.e. Shouldn't developers set the dependency version ranges strictly in the Gemfile?
For example if my Gemfile says that I depend on gem A version 1.0.1 or versions [1.0-2.0), why would I need the .lock?
No, Gemfile.lock makes a lot of sense and is crucial to the concept of automatically picking gem versions. As a developer, you do not need to bother about exact version numbers. You can say "give me whatever version of gem X fits all other versions of all other gems" (by just saying gem 'xyz' without any further information). Or you can tell it to stay within the bugfixing line of an older version of a gem (gem 'xyz', '~> 2.3.0') or whatever.
By adding the exact version in Gemfile.lock you then make sure that the versions stay consistent for all developers (and environments). You make the act of upgrading to a newer version of a gem a conscious (and well-documented) choice instead of a random part of your build/deploy process.
why would I need the .lock?
to install exactly the same versions as all the other guys in the team. Or install in production the same versions that you use in development.
It might happen that a new version of some gem is released while you were collecting sign-offs for your release. You better be sure you install/load exactly the versions that you developed/tested with.
I've recently released version 4 of SBJson. This is a new major version that is not backwards compatible. Since SBJson is widely bundled by other popular libraries I renamed all the classes & enums to make sure it can be used in conjunction with prior versions.
However, I'm not sure how to best handle this situation with CocoaPods. I contributed a 4.0.0 spec to the existing SBJson specs, but I suspect it will be impossible to install version 3.2 and 4.0.0 in the same project. Do I have to clone the 4.0.0 spec into a SBJson4 (notice extra major version number in name) spec as well?
Morning.
If you want users to have both versions installed simultaneously they will probably have to be separate pods.
AFAIK you can't have one pod installed twice in a project. I don't even know how you'd get round the linker errors etc. for that to be possible!