On May 24, 2012 3:25 PM, "shawn" <shawnlandden@gmail.com> wrote:
>
> The last release on the Ruby 1.8 series, 1.8.7, is scheduled for LTS
> starting June, and total EOL June 2013:
> http://bugs.ruby-lang.org/issues/4996
Define LTS since it can mean plenty of things. To most 1.8 is about to hit EOL just think of that year as moving away.
>
> The Ruby 1.9 series brings massive speed improvements over the 1.8
> series due to the new YARV/KRI bytecode interpreter.
>
> In addition to the massive speed improvements, new event-based libraries
> take advantage of new Ruby 1.9 features such as light weight threads
> (fibers), and are therefore 1.9 exclusive.
>
This in itself is not a good reason. The best reason is ruby indirectly forcing debian ruby to somewhat be less ignorant in packaging. Now that rubygems is bundled most complaints about how debian splits ruby can easily be resolved.
> That said, a not unsubstantial amount of 1.8 software does not run on
> 1.9.
Most popular and still being commited to software does support 1.9 and what doesn't should either be dropped or flagged as its either dead or built for 1.8.
>
> We have had the 1.9 series, and the 1.9.1 (through present 1.9.3) API,
> in Debian since before squeeze.
>
> What I would like for Wheezy would be:
> 1. Change the default ruby interpreter in Wheezy to 1.9.3. [1]
> 2. Drop the ruby1.8 option after the release of Wheezy
This could be ignorant. Depending on when you plan to. Before 2013 is ignorant. You've then prematurely decided that people still porting huge projects have to now work around debian ruby more than they already do.
> I think 1.8-only programs are O.K. for wheezy, but if they can't be
> ported to 1.9 should be dropped for wheezy+1 due to lack of ability to
> support the old interpreter.
This is bad management. You should either choose to support them for wheezy's life or not, but killing them at point is not good. Doesn't this usually violate a normal development rule about huge changes in minor releases?
> Also, we should consider how capable we will at doing security fixes
> past upstream EOL of Ruby 1.8[.7]
Keeping 1.8 past its final day puts strain on an already strained debian ruby team. It adds work that shouldn't need to be done and puts you at a bad place.
> Thoughts? Needs? Comments?
You guys are putting more effort into figuring out something simple over the real problems. Mainly debian trying to make updating rubygems taboo (even though the updater works perfectly well with the debian package) and addressing serious short falls in the programming of the gem packager for debian. Though I can't blame you for the latter. Typical ruby stance is to let it all fall and put it on the user to get it right or fail vs. Handling things elegantly. As a friend once put it 'exceptions, errors and input are hard.'
> --
> -Shawn Landden
>
> [1] http://lists.debian.org/debian-ruby/2012/05/msg00046.html