On Thu, Mar 18, 2010 at 11:53 AM, Lucas Nussbaum
<lucas / lucas-nussbaum.net> wrote:
>> On Mar 18, 2010, at 10:15 AM, Lucas Nussbaum wrote:
>>
>> > Note there are not many development communities that are proud of the
>> > fact of having different, incompatible versions of the same software
>> > being widely used at the same time.
>> >
>> > Most other communities solve that by having more stable APIs and making
>> > sure that their important software supports the latest API.

I find the massive and rapid open source contributions to the overall
Ruby ecosystem to be a big source of pride in the Ruby community.

The fact that not everything needs to be on the same version of
everything is what allows fast movement.

Now I realize that there's a different mindset between cutting-edge
development to deployment to system administration.  Clearly having
less stability in the various pieces that make up various applications
raises some issues, and we, the Ruby community have been dealing with
those issues and getting better at it as time goes on.

Allowing that 'instability' is important to a lot of us, believe it or not.

As I said before packaged Ruby solutions and re-packaged gems have
their place, they work for some users, but not for all.


In another reply to this thread you said:

> Such a minor issue" was the split of many software packages into
> seperate Debian packages, not the split of Ruby. ...

> Interestingly, we don't get many complaints on the Debian side about
> that.  The only place where I hear about it is on this list.

I'm not sure what the antecedent of 'that' in the first sentence in
the second paragraph is. But I guess it doesn't matter.  Perhaps the
reason you only hear complaints about the debian packaging of Ruby and
gems here is that there's a much higher proportion of users here who
are actually leveraging Ruby in such a way as to have conflicting
requirements with those of the debian packagers.

And as I said before, it's not really an either or.  You can run both
packaged ruby/gems if you need to in order to run other packages which
require them, along with multiple other installations outside of the
file system space clamed by debian policy within the FHS.

This whole discussion reminds me of the endless static vs. dynamic
typing debate.  Some feel strongly that one should live within a
highly constrained infrastructure, others see benefits in having more
freedom of action, and are willing to deal with the consequences and
use tools and techniques which do that.


>> > Of course, if you want to install many different Ruby and gems versions,
>> > and then try to keep them in a sensible state wrt security issues (which
>> > are not that uncommon in the ruby world), that's your choice.
>>
> On 19/03/10 at 00:35 +0900, James Edward Gray II wrote:
>> You have lost the high ground in the civility argument.
>
> Why? What do you disagree with?

I can't speak for James but perhaps he was reacting to the remark
about security issues not being uncommon in the ruby world.

In fact, although there have been security patches to Ruby/Rails etc.
They haven't been more frequent than most other OSS software as far as
I have experienced, and certainly less than software from a certain
company headquartered in the US Pacific Northwest.  And such security
patches are generally released quickly.

In fact having the ability to apply such changes, without having to
wait for them to be packaged 'downstream' is another advantage to
allowing 'instability.'


-- 
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale