Implement date-based ordering and custom version sort

[micmarc]

This PR adds two new sort options for the Version queryset:

• history_order_by_date - modeled after history_latest_first, when set to True this causes the Versions to be sorted by revision__date_created instead of pk. This can be used in combination with history_latest_first to achieve a reverse chronological sort. Default is False for backwards compatibility.
• get_version_ordering() method - allows for a fully custom and/or dynamic sort implementation in client admins.

Tests and docs are also updated accordingly.

Resolves #991

[micmarc]

@etianen Please review

[etianen]

Sorry it's taken me a little while to get back to you. I'm afraid my life leaves very little time for open source!

This is excellent, thank you for the tests and the docs.

I have one change request - having the get_version_ordering hook returning a Falsy value to mean "use default ordering" seems a bit odd to me. I think it would be better to have get_version_ordering always return a tuple of ordering fields, and move the logic in _reversion_order_version_queryset to the default implementation of get_version_ordering.

That way, people would be able to call super().get_version_ordering() and get the default behaviour, which they could then modify as needed (e.g. add another field). The use-cases are admittedly a bit abstract, but in general I find that behaviour more obvious.

With that done, I'd be very happy to approve your PR and add it to a new minor release.

[micmarc]

@etianen

This is excellent, thank you for the tests and the docs.

Thanks!

I have one change request - having the get_version_ordering hook returning a Falsy value to mean "use default ordering" seems a bit odd to me. I think it would be better to have get_version_ordering always return a tuple of ordering fields, and move the logic in _reversion_order_version_queryset to the default implementation of get_version_ordering.

That way, people would be able to call super().get_version_ordering() and get the default behaviour, which they could then modify as needed (e.g. add another field). The use-cases are admittedly a bit abstract, but in general I find that behaviour more obvious.

I took another look at this and I 100% agree. Initially I was thinking that it would be more like a hook for optional custom logic than an override, but using an override definitely feels more Django-like. I also updated the docs to reflect this change.