SlimGems, a drop-in replacement for RubyGems -- now available
1–10 of 41 posts
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#2We have been working on several JavaScript-related tools that build on top of RubyGems. The most recent versions of RubyGems issued what were, IMO, user hostile deprecation warnings, which confused and alarmed our end users. We were not aware of these changes ahead of time, and it didn't seem to be of much concern to the RubyGems maintainers.
For critical infrastructure like package management, these kind of changes can be difficult to deal with. We're switching all of our projects to SlimGems, and are going to be contributing code for improving its use as a library for other software to build on.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#3We have been working on several JavaScript-related tools that build on top of RubyGems. The most recent versions of RubyGems issued what were, IMO, user hostile deprecation warnings, which confused and alarmed our end users. We were not aware of these changes ahead of time, and it didn't seem to be of much concern to the RubyGems maintainers. For critical infrastructure like package management, these kind of changes…
The Ruby/Rails way: When the drama created by oversized egos inevitably comes to a head, fork/replace the project and badmouth the other guys.
Allow me to rewrite your statement to be ruby-drama-free:
We have been working on several JavaScript-related tools that build on top of RubyGems. As the most recent versions of RubyGems have begun deprecating standard APIs that we and many other projects rely on, we have decided to fork the project, with the intention of maintaining an alternative to RubyGems that maintains ongoing compatibility with the existing API.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#4I'm all for projects like SlimGems. You can be a cowboy in your app, you can be a cowboy in your framework, you can even be a cowboy in your language, to some extent. But package management should be as absolutely rock-solid and considerate as possible. RubyGems has been anything but. Patch versions introducing breaking changes, outwardly hostile deprecation warnings, and some fairly hostile developers. There needs to be more attention paid to Semantic Versioning (http://semver.org) and less breaking.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#5I'm all for projects like SlimGems. You can be a cowboy in your app, you can be a cowboy in your framework, you can even be a cowboy in your language , to some extent. But package management should be as absolutely rock-solid and considerate as possible. RubyGems has been anything but. Patch versions introducing breaking changes, outwardly hostile deprecation warnings, and some fairly hostile developers. There needs…
Just a small distinction: semantic versioning does nothing to prevent you from breaking, it just take the high road by calling it a different version number.
My big issue with semantic versioning, which I endorse on the whole, is that it says it's okay to change public interfaces between major versions. That's fine if your environment allows you to activate two different versions of a library, but most don't. In this case, it means even if RubyGems was called 2.0, you'd have the same technical problems if you have libs with dependencies on RubyGems 1.x and other libs with dependencies on RubyGems 2.x. Modules really should be used to namespace interfaces across major versions.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#6RubyGems 1.8.5 actually breaks Rails 2.3.11. Just to be really clear there: the package manager breaks the 4 month old release of the most important framework for that language, on a branch that until rather recently was still the preferred production stack (and is still used by a bazillion websites).
I was flabbergasted. Really? Nobody thought to check to make sure the package manager release doesn't break Rails 2 completely? I'm glad to see Loren and crew step up.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#7I'm all for projects like SlimGems. You can be a cowboy in your app, you can be a cowboy in your framework, you can even be a cowboy in your language , to some extent. But package management should be as absolutely rock-solid and considerate as possible. RubyGems has been anything but. Patch versions introducing breaking changes, outwardly hostile deprecation warnings, and some fairly hostile developers. There needs…
Just a small distinction: semantic versioning does nothing to prevent you from breaking, it just take the high road by calling it a different version number. My big issue with semantic versioning, which I endorse on the whole, is that it says it's okay to change public interfaces between major versions. That's fine if your environment allows you to activate two different versions of a library, but most don't. In this…
The whole point of versioning, however, is to designate how big changes are between versions. There's a world of difference between 0.2.1 to 0.2.2 versus 0.2.1 and 0.3.0. That's what I'm mostly concerned about- patch versions should be a relatively low-stress change between versions. Changing that minor or major number to designate something large is coming is important.
I agree that it doesn't necessarily mean that you won't have to rework your local code, but particularly with projects like RubyGems (which are more end-user than code integration points), it's more important to know whether or not upgrading will break your entire process.
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#8I'm glad I never upgraded to see these issues and that someone is taking care of them
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#9RubyGems 1.8.5 actually breaks Rails 2.3.11. Just to be really clear there: the package manager breaks the 4 month old release of the most important framework for that language, on a branch that until rather recently was still the preferred production stack (and is still used by a bazillion websites). I was flabbergasted. Really? Nobody thought to check to make sure the package manager release doesn't break Rails 2 c…
Don't forget rake. The latest version of rake broke all versions of Rails (don't know if this got fixed yet).
Re: SlimGems, a drop-in replacement for RubyGems -- now available
#10Earlier quoted context omitted.
Just a small distinction: semantic versioning does nothing to prevent you from breaking, it just take the high road by calling it a different version number. My big issue with semantic versioning, which I endorse on the whole, is that it says it's okay to change public interfaces between major versions. That's fine if your environment allows you to activate two different versions of a library, but most don't. In this…
The whole point of versioning, however, is to designate how big changes are between versions. There's a world of difference between 0.2.1 to 0.2.2 versus 0.2.1 and 0.3.0. That's what I'm mostly concerned about- patch versions should be a relatively low-stress change between versions. Changing that minor or major number to designate something large is coming is important. I agree that it doesn't necessarily mean that…
It's important as a communication tool. But you'd still be in a world of hurt because that logical distinction doesn't affect execution semantics. The problem is exacerbated once transitive dependencies enter the picture.
As a concrete example, the redis-rb gem went to 2.0 and completely broke API compatibility. They did everything right by the semantic versioning book. I used about 10 libraries built atop redis-rb, but never used redis-rb directly. About half the libs updated and required the use of redis-rb 2.0, the other half did not. Moreover, the gem dropped protocol support for the old redis-server, too, so it forced a redis-server upgrade.
This was an absolute mess to work out because updating 10 libs at once is basically insane. And the whole thing could have been avoided if modules were used to namespace, allowing activation of both sets of classes.
But, anyway, this isn't to say semantic versioning has no value. It's just not a solution to a library that keeps changing its public API either.