>
> On Apr 22, 2004, at 17:58, Gavin Sinclair wrote:
>> Me neither, but then I've never combined a *lot* of libraries into a
>> single project.  I've certainly seen it mentioned a few times on the
>> list.
>>
>
> To my agile ears, that would suggest it is therefore premature for you
> to be working out a versioning system. Perhaps the best designs and
> systems come from solving a need, rather than thinking about what a
> need _might_ be.  I know I'm sounding negative here: I'm not, though. I
> really want gems to succeed. We need it. I just feel that part of the
> success comes from keeping it light _until_ it has to become heavier.

I disclaim any valuable opinion on versioning :)  Chad and Rich are
(probably) the right folks to discuss that.

My take on the whole thing is this: the best general architecture for gems
is sandboxing, for ease of management.  An agile approach is evident,
because that architecture has *enabled* nice features: gem_server being a
good documentation browser, for instance.

Support for versioning is easy, based on that architecture.  There's no
reason *not* to do it, because it's backwards-compatible, and there's only
one real way *to* do it [1], so we're not going down a path we'll regret. 
I hope it's rarely used: I hope that most libraries support the latest
version of their dependent libraries most of the time, and don't need to
limit themselves.

But I think it's easy to argue *for* versioning in theory as well.  We'll
see how the practice turns out, but my main point is that it's not a major
distraction; it's a simple consequence of a good approach.  Others in the
development team will probably see it differently :)

RubyGems is improving so fast it's almost scary, so it's obviously well
grounded in some sense.

Cheers,
Gavin

[1] UI considerations for versioning is definitely something that could
need some work, but I think the fundamental approach is sound.