Bisect points to

9982e400c7b21afdebe364d8eb1a8565c5383242 is the first bad commit
commit 9982e400c7b21afdebe364d8eb1a8565c5383242
Author: Thomas A Caswell <tcaswell@gmail.com>
Date:   Mon Aug 22 15:57:53 2016 -0400

    Merge pull request #6919 from efiring/integer_locator
    
    ENH: Rework MaxNLocator, eliminating infinite loop; closes #6849

:040000 040000 95c51fc30de8968e26068ffb49d5e7323a2ca0a6 2782be8d70b37e6658f1e896ccbd217e142be26b M	lib

the backport of #6919. cc @efiring.

First, evidently cartopy was using a steps kwarg that was inconsistent with the API; the fact that it worked was accidental. To be consistent with the API, the equivalent steps array would be steps=[1, 1.5, 1.8, 2, 3, 6, 10]. As the docstring says, it must start with 1 and end with 10. If you had used that steps array, you would have gotten yet another result with v1.5:

In [4]: degree_locator = MaxNLocator(nbins=9, steps=[1, 1.5, 1.8, 2, 3, 6, 10])

In [5]: degree_locator.tick_values(-61.2479231, 68.41835367)
array([-72., -54., -36., -18.,   0.,  18.,  36.,  54.,  72.])

Second, I think the difference in behavior is an improvement, in that it does a better job of getting close to the target (maximum) number of bins (tick intervals within the limits), given the available steps.

I will add a note to the documentation, but I don't consider the new behavior to be a bug and I will not try to restore the old behavior. This will be one of the relatively few areas where behavior in 2.0, even with classic settings, is not exactly the same as in 1.5.x.

Evidently I also need to add validation of the steps kwarg.

I'm moving this to milestone 2.1

Maybe the validation part, but this issue is a missing documentation problem of a change in 2.0; it should go in 2.0, or at most 2.0.1.

I am fine with the documentation being into 2.0, but we need to be extremely careful about not tagging too much issue into 2.0, else we will never release 2.0. There are way too many issues and PR being tagged 2.0.1.
IMO, now that we have a release candidate, the smallest amount possible of commits should go in the 2.0. Nothing prevents us from releasing 2.1 soon after.

The 2.0.1 milestone is irrelevant for the purposes of releasing 2.0; it's a nice-to-have list, but not that important.

For 2.0, I bumped everything that's not documentation or imminent (I assume @tacaswell wants those last two features in) or a regression.

Wait wait, I forgot one very important thing; tests were run in classic style to minimize differences with older releases. If I compare classic mode with 1.5.3, then using the valid steps values, I can get a consistent result, and that's really all I was hoping for because otherwise we need either a bunch of test images or a really high test tolerance.

So I must apologize for all the milestone flipping, but since this is only a problem when given invalid input, I guess it's not that important to document in 2.0 specifically. We only really need the validation part, which can go into 2.1.

I have the validation plus a bugfix (an inconsistency with "integer=True") ready to go, and I will add a doc note soon and then make a PR. With the reimplementation of the inner algorithm in MaxNLocator I think there will be cases where the result differs, so it would be good to mention this. I don't see any problem with including it in 2.0. With luck I will have the PR ready tonight.