> “First, SUVersionComparision is not a subclass of NSSortDescriptor, so it can't be just made that because of backward compatibility.”
> What backward compatibility restriction is that? As long as the app developer recompiles with the new framework, it should work just fine.
> The patch does not change any existing functionality in SUStandardVersionComparator; it only adds the NSSortDescriptor nature.
The developer also has to change the code. My point is that your proposal REALLY changes the Sparkle API, and this should not be done at this point in the development cycle.
> “Moreover, the patch does not take into account the possible ovverride of SUStandardVersionComparison.”
> I disagree. A subclass that overrides compareVersion:toVersion: should continue to work, and should inherit the same dual usefulness as an NSSortDescriptor.
But it's not used, you're using SUStandardVersionComparison, not any subclass. So I disagree with your disagreement.
> “First, SUVersionCompar ision is not a subclass of NSSortDescriptor, so it can't be just made that because of backward compatibility.”
> What backward compatibility restriction is that? As long as the app developer recompiles with the new framework, it should work just fine.
> The patch does not change any existing functionality in SUStandardVersi onComparator; it only adds the NSSortDescriptor nature.
The developer also has to change the code. My point is that your proposal REALLY changes the Sparkle API, and this should not be done at this point in the development cycle.
> “Moreover, the patch does not take into account the possible ovverride of SUStandardVersi onComparison. ”
> I disagree. A subclass that overrides compareVersion: toVersion: should continue to work, and should inherit the same dual usefulness as an NSSortDescriptor.
But it's not used, you're using SUStandardVersi onComparison, not any subclass. So I disagree with your disagreement.