James Carlson wrote:
> 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.
>
Agreed. This is just the first case I've personally seen where the
dependency and dependee had this sort of relationship. The rules being
discussed all make sense to me, it just wasn't clear to me that everyone
else understood them that way.
I still think the project team needs to pick either Patch or Micro. My
guess is Patch is probably what is desired.
- Garrett
