gems

[Daniel Yoder]

wavesters!

curious about opinions on managing all the waves gem dependencies. am
considering instituting the following draconian rule:

ALWAYS SPECIFY THE VERSION NUMBER OF ANY GEM BEFORE INTRODUCING IT

and i mean the EXACT GEM VERSION

like this:

gem 'rack', '= 1.0.0'
require 'rack'

the advantage of this, of course, is to prevent things like the 0.8.2
fiasco, where it just stopped working because of a change in rack.

thoughts?

z

[Krishna Krishnamaneni]

I think its a good idea, We probably have to require a range a
versions, something like this gem 'library', '>= 2.2.0', '< 3.0' . i
had the same problem with Sequel, i upgraded to the new one and it
failed.

--
Regards,
krishna krishnamaneni.

[Jerry West]

Does your suggestion imply a commitment to testing and releasing new
waves gems fairly quickly after a dependent gem has been upgraded?

Clearly I'll still have the 'old' gem around for waves to use but at
some point I may start to believe that waves is un-maintained or not
actively supported (sometimes the kiss of death for OSS) if I see that
it "still" relies on "old" versions of important software.

I agree that I would rather not have waves break when I upgrade rack
but I don't want to keep multiple copies of everything lying around
for too long.

Just a thought,
Jerry

[Hemant Borole]

I agree with specifying the exact version number given that most of the gem upgrades fail to be maintain backwards compatibility.

Hèmant Borolè

On Sun, Jul 19, 2009 at 5:54 PM, Daniel Yoder <d...@zeraweb.com> wrote:

[Roberto Gamboni]

yeah, I agree with the idea of exact version number too.

Having a range would be nice, but it defeats the purpose of avoiding fiasco due to missing backward compatibility.

And i like the idea of EXACT gem version because it gives us a precise configuration that we know IT WORKS and someone already used and tested.

In alternative (or better as a plus) we could create a document with the working gems configuration of each one of us. At the end the exact gem version could be a conservative solution, so having the information about how someone is pushing farther in the development with some specific gem (i'm thinking now about KK with sequel, rue with rack related gem, zeraweb with ruby-based views) would be a good information to have. But maybe too confusing?

polymar

2009/7/19 Hemant Borole <hemant....@gmail.com>

[John Haltiwanger]

On Jul 20, 7:06 pm, Roberto Gamboni <cproby2...@gmail.com> wrote:
> yeah, I agree with the idea of exact version number too.
> Having a range would be nice, but it defeats the purpose of avoiding fiasco
> due to missing backward compatibility.
> And i like the idea of EXACT gem version because it gives us a precise
> configuration that we know IT WORKS and someone already used and tested.
>
> In alternative (or better as a plus) we could create a document with the
> working gems configuration of each one of us. At the end the exact gem
> version could be a conservative solution, so having the information about
> how someone is pushing farther in the development with some specific gem
> (i'm thinking now about KK with sequel, rue with rack related gem, zeraweb
> with ruby-based views) would be a good information to have. But maybe too
> confusing?
>
> polymar

If we could automate it as a rake task and feed the data to a
statistical app on rubywaves.com, this could be pretty awesome. I'm
thinking here of something along the lines of smoke testing, where the
test suite is run against a local configuration and either errors or a
success is sent to an aggregating app. This would also help us avoid
fiascos of all sorts by providing clear boundaries as to what works
and what doesn't work.

[Daniel Yoder]

Jerry,

A very good point that I forgot to respond to ... =)

I guess my response is that I'd rather have a working stable version
at any given time, even if we are slow to get the next release out
(which we have been, generally). Generally, I'd prefer to "catch up"
to the latest versions, at least in edge.

So ... stable might be "old" relative to current gem versions, but
will still run. Edge will try to stay current, but you use at your own
risk.

Dan