Wow, RTG was killed by Sidekiq requiring Redis 4. Not the first company killed by the upgrade treadmill I'm sure. People should be on the lookout for projects like Sidekiq that force upgrades, and push back on them and/or volunteer to help make it backward-compatible and/or hard-fork it if the devs won't agree to it.
Here's how that works:
1. You see an announcement. "Foobar 2.0 requires Bazz 4.x"
2. You make a friendly suggestion that they not break backward compatibility with Bazz 3.x
3. If that fails, you volunteer to maintain backward compat yourself.
4. If they reject your patches, you hard fork Foobar and try to kill the original project, as they are clearly not good open-source citizens and must be replaced.
Are they really not "good open-source citizens" ? Keeping backwards compatibility doesn't mean a project is healthy, far from it.
Volunteering to maintain backward compat. It can be very damaging in an open-source project. So let's admit you become the "redis 3.x" guy for Sidekiq. Now, every time the sidekiq project moves or tries to moves forward, they have to see with you to maintain compatibility ? Do they know you ? Are you already a contributor ?
Also, who really needs to stay on Redis 3 there ? Are we blaming Sidekiq for killing RedisToGo, A RackSpace company, because they didn't "have the time" to upgrade to redis 4 ? Sounds like business needs. Business needs are rarely good open-source citizens.
> Keeping backwards compatibility doesn't mean a project is healthy, far from it
How does backward compatibility mean a project is unhealthy?
> Do they know you ? Are you already a contributor ?
How is someone who shows up and volunteers to help not a contributor by default?
> because they didn't "have the time" to upgrade to redis 4
Time is money, and when you reach a certain amount of money, your business stops being profitable. So yes, presumably they literally didn't have "time" to do so.
>How does backward compatibility mean a project is unhealthy?
It doesn't mean it is, yes. Compat or not isn't a "healthy metric" at all.
>How is someone who shows up and volunteers to help not a contributor by default?
As a maintainer of a serious project, would you accept a PR adding back backward compatibility, with the premises of "i'll maintain it", from a random person ? It's not an healthy decision at all for the project to accept that, actually, depending on the project and the implications.
So what does one need to do in order to go from "random person" to "accepted contributor"? Do I need to fix typos on the README for awhile? Do I need to fix random bugs for awhile? Or do I need to go to work for the company that sponsors the project? We shouldn't automatically assume that a more restrictive approach is more "healthy" here. It all comes with tradeoffs.
Yes, it was the point I was trying to make: it all comes with tradeoffs. Sidekiq choosed to not go forward with backwards compat, and I don't feel it make them "bad citizens" like you implied in your original comment.
RTG decided not to offer future versions of Redis past 3.x. Once the owners stop investing time and effort into a company, they're choosing to let it die while pocketing any remaining profit.
Do you think no software should ever upgrade dependencies? Do you think it's unreasonable to want to take advantage of new features in newer versions? Why should I lock Sidekiq to Redis 3 forever? When am I allowed to require Redis 4?
Here's how that works:
1. You see an announcement. "Foobar 2.0 requires Bazz 4.x"
2. You make a friendly suggestion that they not break backward compatibility with Bazz 3.x
3. If that fails, you volunteer to maintain backward compat yourself.
4. If they reject your patches, you hard fork Foobar and try to kill the original project, as they are clearly not good open-source citizens and must be replaced.