As reported by @mildwonkey and discussed here and here, the Translate operation panics with index out of range [2] with length 2 when there's more than two majors (for instance 0.0, 1.0 and 2.0) in the lineage.
So, after some debugging, I realized the calc of the intermediate variable _basis was wrong, because as stated in the comment, it keeps the index of the first schema in each major version within the overall canonical schema sort ordering, so for example, with versions: 0.0, 0.1, 0.2, 0.3,1.0, 1.1 and 2.0, I'd expect it to be [0, 4, 6] but it was used to be [0, 4], causing the aforementioned panic.
So, I tweaked it a bit to get what I guess it's the expected result.
Also added a test case that covers it, following Red-Green-Refactor!
This should make this example provided by @mildwonkey to work.
As reported by @mildwonkey and discussed here and here, the
Translate
operation panics withindex out of range [2] with length 2
when there's more than two majors (for instance0.0
,1.0
and2.0
) in the lineage.So, after some debugging, I realized the calc of the intermediate variable
_basis
was wrong, because as stated in the comment, itkeeps the index of the first schema in each major version within the overall canonical schema sort ordering
, so for example, with versions:0.0
,0.1
,0.2
,0.3
,1.0
,1.1
and2.0
, I'd expect it to be[0, 4, 6]
but it was used to be[0, 4
], causing the aforementioned panic.So, I tweaked it a bit to get what I guess it's the expected result. Also added a test case that covers it, following Red-Green-Refactor!
This should make this example provided by @mildwonkey to work.