Re: Core support for Gems, and namespace

On Wed, Jul 28, 2004 at 11:13:58PM +0900, Gavin Sinclair wrote:
> > Regarding Austin's example, diff-lcs-1.0.2 would replace diff-lcs-1.0.1
> > in the last RPA release, so nobody would install 1.0.1 anymore (they'd
> > get 1.0.2). diff-lcs-1.1.0 would be shipped with a later release.
> > End users/developers can choose between:
> > (1) committing to the API from a particular RPA release: at that point,
> >     you use all the libs *from that release*. No need to perform
> >     cherry-picking with a  require "foo/requirements".
> 
> ... cherry-picking is not necessarily a bad thing.  In fact, I don't
> see why it's even to be avoided.  A coder knows what their
> dependencies are, and will test their code with certain versions of
> those dependencies. 

RPA is meant to make life easier for the upstream developer. He'd require
some API and the RPA team would make sure it is going to be satisfied
and test it for him.

Going back to the diff-lcs example: imagine somebody decided to depend
on diff-lcs 1.0.1. Austin is telling us that *nobody* should use that
anymore since it's buggy and that it's safe to use diff-lcs 1.0.2 in
the places where 1.0.1 was used before. However, if the upstream devel
had used the require 'foo/requirements' technique, with
  require_gem 'diff-lcs', "1.0.1"
it would still be using the old, broken one. And I wouldn't expect him
to be looking forward to releasing again just to change that to 1.0.2.

Now, you might say he could have done
  require_gem 'diff-lcs', ">=1.0.1", "< 2.0"
(that's no longer strict cherry-picking though) however that will only
work if the person in charge for the dependency follows a consistent
versioning scheme (IIRC Austin follows the common x.y.z scheme so in this
particular case it'd be OK, but that's often not the case), i.e. one
must be able to *predict* when the API will be changed. That's why I
made so much noise on rubygems-developers about the need for versioning
policies or at least API versioning standards (i.e. maintaining an API
revision num, unrelated to the global version num).

> There's no dependency set in a Ruby project
> that's so large as to be beyong the capability of one person to
> manage.

It's doable, but a devel. might not want/have the time to track the
changes in the deps. For instance, consider instiki's case: Madeleine 0.7
was released recently but DHH doesn't know if instiki 0.9.1 would work OK
yet. If the RPA process was working, the RPA team + beta testers would be
testing that (think of Debian sid) instead of leaving all the work to DHH.

> That's not to dismiss the RPA approach one jot.  Its emphasis on
> quality is excellent.

I'm sure everybody has set quality as a long-term goal, I'm just trying
to accelerate this by bootstrapping RPA :)

-- 
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com