[Rubygems-developers] PATCH: respect requirements of gems
chad at chadfowler.com
Fri Apr 23 07:36:20 EDT 2004
On 23/4/2004, at 7:25 AM, Eivind Eklund wrote:
> On Thu, Apr 22, 2004 at 05:40:58AM -0400, Chad Fowler wrote:
>> I've thought about this quite a bit, and while I understand what
>> trying to do and the code is obviously fine, I just can't force myself
>> to like this. I was more open to Eivind's other suggestion of having
>> separate, single, incrementing number for version compatibility, but
>> Jim's 1.*.* suggestion still strikes me as being the least offensive.
> I've missed this suggestion, and can't find it in the archives (nor in
> the mail I've received from the list). Mind a quick recap?
> BTW: From my point of view, library versioning is inherently offensive.
> I find everything I've ever seen in the area at least slightly
> offensive, either being non-functional, ugly, incomplete, too complex,
> too much work, or (usually) a combination of several of them. It is a
> problem that is very tempting to just disregard or go for some hacky
> solution to - however, then stuff just don't work and the user is
> left up the creek :-(
> As an example, I'm seeing this with the single-version solution and
> in FreeBSD ports. It has gone so far that we're modifying ports
> one-by-one in an attempt to make it possible to disable gettext to
> the sideeffects of the versioning problem on ONE library. This
> modification to at least hundreds (and possibly thousands) of ports,
> is something we have to do even with us owning the version bumping and
> release engineering for the packages, and doing formally correct
> versioning (single-number variant).
> I'd LOVE to see a better solution to this than the ones I've proposed -
> they are just the ones that leave the least amount of bad taste in my
Same here. I think we have slightly different definitions of what a
"bad taste" is, but we would probably agree that nothing proposed so
far tastes great. :)
Something I'm sure of, though, is that whatever we do will be better
than what already exists (in terms of the entire picture of where
things are with library management in Ruby).
More information about the Rubygems-developers