John Plocher writes: > Garrett D'Amore wrote: > > *provided* that we all understand that this doesn't set a precedent > > where someone could use this case's binding to bring along the > > dependency with a stricter binding requirement > > I believe that such a presumption is at the heart of the whole > binding/dependency scheme. If you have Patch, and depend on me, > but I only have Minor, then QED - you can only *do* Minor. > > Duh! :-)
Another way to look at it is this: if we forced every project with one or more dependencies to write its binding in terms of the most-restrictive of the bindings of those dependencies (recursively, of course), then we'd end up with a mess any time a project needed to change its release binding -- we'd have to track down all of the dependent projects and determine whether this dependency was the limiting factor in its binding. That's silly. Instead, we write release bindings that apply to the project at hand. Dependencies are restrictions in addition to and quite apart from that. In other words, it's a boolean AND relationship (need this kind of release AND these dependencies satisfied) and not an OR relationship. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
