Hacker News new | past | comments | ask | show | jobs | submit login

Let me give a more concrete example: if something was developed in Rails 3 but was not updated for Rails 4, then I assume it won't work (I'm on Rails 4.1).

This doesn't mean the entire project needs to be re-written. Often times, a simple note that says "compatible with Rails 4" would be satisfactory.

But if even the readme is not updated, that makes it difficult for me to put any faith in it. And unfortunately there are tons of projects like that on GitHub.

That's a fine example. It has dependencies, the dependencies change quickly, so the project needs updating.

Let me give a counter-example. PriorityQueue is a data structure implementation published as a Ruby gem in 2005: https://rubygems.org/gems/PriorityQueue/versions/0.1.2. It has not been updated since, because it doesn't need to be. It just works. (It could use better docs, but even that would be a one-time change.)

Similarly, I have a gem that helps build searches with ORMs - https://github.com/nathanl/searchlight. It doesn't directly depend on any ORM, just the "chained method calls to build queries" interface that they implement. That means I don't need to update it when ActiveRecord or Sequel or Mongoid gets a new feature. Which means I commit far less often. I consider it feature complete and only make bug fixes, which should eventually stop.

At that point, it may look abandoned, but it won't be. Just stable. Which I consider a good thing.

The Gemspec should have an upper limit on major Rails versions as a general best-practice.

But yeah, this happens all the time in this space.

Unfortunately, Rails APIs change a lot more than the time-trusted POSIX APIs.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact