Comment 8 for bug 391965

> SUVersionComparision is a protocol, not a class. That basically invalidates all your comments.

No, it doesn't. I've only ever been talking about the class, SUStandardVersionComparator. I thought you were talking about it because you keep talking about subclasses; protocols don't have subclasses because they aren't classes.

I never touched the SUVersionComparison protocol. It's still there, unchanged.

> And I don't think it makes sense to compare version numbers inconsistently. If a developer needs a different way to compare version number than this says something about the format of the version numbers he uses, and that is relevant for this situation just as well.

That's why SUStandardVersionComparator is only the *standard* version comparator. That hasn't changed: it was before, and still is. The only difference is that now you can use it anywhere you can use a sort descriptor.

I think I've finally guessed your complaint: You don't like that SUAppcast sorts using the standard version comparator, and doesn't look for an application-defined version comparator. Since application-defined version comparators will conform to the SUVersionComparison protocol but probably not be subclasses of the SUStandardVersionComparator class, you see this as a breaking API change.

It's not. It's an omission, and it's fixable.

That does lead to a question, though: How should SUAppcast obtain the application's version comparator? It doesn't have a reference to its SUUpdater; should I add one? (sharedUpdater is plainly wrong, since the appcast may be for a different updater.)