On 12/17/09 8:27, Stuart McCulloch wrote:
2009/12/17 Guo Du<mrdu...@gmail.com>
On Wed, Dec 16, 2009 at 5:37 PM, Stuart McCulloch<mccu...@gmail.com>
wrote:
So +1 to trying the intersection approach.
Intersection ONLY is not safe for the case:
Host version [2.0.0,3.0.0)
[2.5.0,2.9.0)
Fails, when host is importing 2.1.0 this would cause fragment to fail.
depends when the intersection was made - if it was done before the host
resolved
then the host's import range would shrink to the intersection: [2.5.0,2.9.0)
and the
host plus fragment would not be in conflict.
now if you're attaching the fragment to an already resolved host then I
believe the
resolver would look at the existing wires, not the original range - so if
the host was
already wired to 2.1.0 then the fragment wouldn't be able to attach
dynamically
but then this is still correct (afaik) in that you can't dynamically attach
a fragment
that conflicts with the resolved host (btw, do we support dynamic
attachment?)
No, we don't.
We may have following condition to enable fragment:
1. exact version match or
2. host version range inside all fragments version or
3. all fragments and host share intersection + dynamic verify the
actual imported version is inside intersection
(p.s. I am not sure "dynamic verify the actual imported version is
inside intersection" is viable or not. If not, we could do at least
step 2 which will help both Andreas's and FELIX-1919 case )
these still fall under 'intersection' imho (ie. the intersection should
apply to the
host and fragment) but let's see what Richard's algorithm actually looks
like :)
The intersection approach will create a new version range each time a
fragment is added and the next fragment will be compared against that
range in bundle ID order. I don't think this will allow for any valid
cases since we are always making the allowed version range more narror.
-> richard
-Guo
