3 ms·
> "more or less" ... on 6 Oct 2011. They announced their plan. It was perfectly reasonable, and Ruby 1.9 was available way before that (2007) and at that time
by lloeki 13y ago
> "more or less"
... on 6 Oct 2011.
They announced their plan. It was perfectly reasonable, and Ruby 1.9 was available way before that (2007) and at that time 1.9.3 was around the corner, so the clock was obviously ticking way before this announcement.
Ubuntu (and Debian) choses to stick on versions with releases, and maintain security as backported patches if need be, so the onus is now on them to secure their system.
It is a double edged sword to choose to rely on a system that favors sticking with older releases and rely on its own patches for bugfixing and security. One one hand you get tight integration between packages and platform stability, but on the other hand you get bitten back in such cases, and you can't blame upstream for that.
- rlpb 13y ago> Ubuntu (and Debian) choses to stick on versions with releases It's not as simple as just choosing. Every single package that depends on ruby 1.8 needs to move on before ruby 1.8 can itself be removed from the Debian or Ubuntu repositories. Either that, or the decision has to be made for laggard dependent packages to be removed. This takes time. In Ubuntu, ruby1.8 is in main, which means that the Ubuntu Security Team will take care of the backported update.
- lloeki 13y ago> It's not as simple as just choosing. Every single package that depends on ruby 1.8 It is a matter of choosing, although that choice obviously goes beyond "hey let's bump the version of that lonely package". The choice I refer to is holistic, and also covers how many packages a distribution choses to make depend on ruby, such as the decision to package gems, with overarching (positive and negative) consequences.
- rlpb 13y agoThat is the cost of being able to "apt-get install <foo>" without having to learn details of the packaging system that yet another language community expects everyone to learn and use, for each <foo> that one wants to install. Remember that dependencies go in multiple directions. Ruby is not necessarily at the top of the stack. I might, for example, want to deploy my Python application stack with puppet. Which requires Ruby. If the choice is "don't use a distribution", then have fun with that. If the choice is "use a distribution, but don't use it for my stuff", then what makes you so special, and how does this scale to every community that wants the same thing?