We have a problem in using the target build number in the percentage calculation. At the point that the phased updated percentage is used, we don't actually know the target yet.

When we read the index file, we filter out any images that have a percentage >= the calculated pu percentage. *Then* we calculate the winning update path from the index, which tells us the build number target.

If we changed the implementation such that the winning upgrade path was calculated first, this would imply a subtle semantic difference.

Under the old regime, let's say your upgrade path is 10:11:12 but your phased percentage is > the percentage for upgrade 12. You'd filter out the update to 12 but you would still potentially update to 11.

If we switched things around to calculate the update first, and we use the same scenario (path is 10:11:12 but device-% > image-%) then we'd just not update the device at all. Maybe that's okay, and maybe it's what was originally (albeit underspecified ;) intended.

The other possibility is that if our target is 10:11:12 but 12 is filtered out, then we'd refine the upgrade path to 10:11 and then recalculate the winners from all candidates. I think that would lead to the same outcome as before, but it's more tricky to implement and thus riskier for a quick bug fix.

We have a problem in using the target build number in the percentage calculation. At the point that the phased updated percentage is used, we don't actually know the target yet.

When we read the index file, we filter out any images that have a percentage >= the calculated pu percentage. *Then* we calculate the winning update path from the index, which tells us the build number target.

If we changed the implementation such that the winning upgrade path was calculated first, this would imply a subtle semantic difference.

Under the old regime, let's say your upgrade path is 10:11:12 but your phased percentage is > the percentage for upgrade 12. You'd filter out the update to 12 but you would still potentially update to 11.

If we switched things around to calculate the update first, and we use the same scenario (path is 10:11:12 but device-% > image-%) then we'd just not update the device at all. Maybe that's okay, and maybe it's what was originally (albeit underspecified ;) intended.

The other possibility is that if our target is 10:11:12 but 12 is filtered out, then we'd refine the upgrade path to 10:11 and then recalculate the winners from all candidates. I think that would lead to the same outcome as before, but it's more tricky to implement and thus riskier for a quick bug fix.

Thinking...