Quote:
Originally Posted by Ken Case
Short version:
We tracked down this bug yesterday afternoon and the fix will be in the next update.
Long version:
For the curious, the problem was with reading synchronized review dates which were in the past: the system which last modified the next review date wouldn't bother writing it when it could be implied by the the previous review date and the review interval. But when other systems which read that review date would calculate the next review date for the project, they would always choose the first future iteration of that interval.
In other words, if you have a project which is set to review every Friday and you last reviewed it two weeks ago, it would end up assigning a review date of the upcoming Friday rather than last Friday.
So this didn't affect people who always did their reviews on the same device (probably pretty common if you had a weekly review routine involving the same device), nor did it affect people who never let a review slip past its review date and were synchronizing their devices regularly (since the synchronized next review dates would be read while they were still in the future, and thus wouldn't be skipped).
Sorry this slipped through the cracks! We're now testing a fix for the 1.0.2 release which we're planning to submit within the next few days.
|
I downloaded the update.
I still don't understand why projects don't queue up by staleness in review mode (iPad version) as they do in the desktop version. Why would they queue up according to the order in the project menu? I think I'm missing something.
thanks!!