Re: status of 1.9[.3] and wheezy
On 02/10/11 10:23, Antonio Terceiro wrote:
> Lucas Nussbaum escreveu isso aí:
>> So there are three things to decide.
>>
>> 1) should we upload that version to unstable, or to experimental? I'm
>> very much inclined to upload it to unstable, since it seems better than
>> 1.9.2 in many regards.
>
> I think we could have it in unstable, since in theory the compatibility
> level stays the same.
>
>> 2) should we make that version the default for wheezy? We don't need to
>> decide that yet, but I think that we should seriously consider that now.
>> (and I'm in favor of doing it). The transition is looking very good
>> according to http://pkg-ruby-extras.alioth.debian.org/wheezy/ .
>>
>> 3) if we make 1.9.3 the default, should we drop 1.8 ? I'm also in favor
>> of doing that, to reduce the maintenance cost.
>
> I agree with making 1.9 the default, since that's what everyone who
> works with Ruby today expects. On the other hand, I think it's premature
> to drop 1.8 since it is still heavily used and there is a lot of code
> out there that does not support 1.9. For example, look at this report
> from New Relic:
>
> http://blog.newrelic.com/2011/09/28/state-of-the-stack-a-ruby-on-rails-benchmarking-report-sept-2011/
That's a circular argument: those applications are almost certainly
running on 1.8 because that's the distro-supplied ruby version (or was
when the app was born), not because they've explicitly chosen it in
preference to 1.9.
>
> I think the sensible thing to do would be to drop 1.8 for Wheezy+1, and
> to announce this fact on the Wheezy release notes.
>
The question is, what is the Ruby in Debian *for*? Its primary purpose,
surely, is to run the packaged end-user applications, like redmine,
which the non-developer user wants to use. If that's true, we don't
need any versions other than those required by the applications we want,
so from that point of view 1.8 can be dropped as soon as all the
packaged applications work.
Does Debian Ruby have a goal of providing a first-class deployment
platform for third-party Ruby applications? I would argue that it's a
goal not worth chasing because the libraries move too fast, and that it
should be made clear that the user who wants to do this should be using
RVM, rbenv+ruby-build or even checkinstall, and make that as easy as
possible to do: it's worth knocking up virtual packages to install the
dependencies for building the various interpreters, but not the
interpreters themselves.
I personally think 1.8 should be dropped from Wheezy in favour of having
a 1.9.3 system ruby. I say this with a couple of MLOC running on
1.8.7-p302 in squeeze that I'll have to update to 1.9. It's better to
do a small job well than half-do a bigger one.
--
Alex
Reply to: