Just closed and reopened to restart Appveyor. There were no actual build errors.

Squawk

Bump.

I don't see the point in changing this, but if you are going to do this, can you replace the camel case with something more pythonic? (to for example label_minor, which btw is very confusing as this does not turn on the minor labeling but the labeling on none decade elements.)

You are absolutely right. I made both the camel->_ change and updated the docs slightly. Thanks for the explanation. Hopefully this change is no longer a controversial one.

I just remembered that the whole point of the change was that the sense of the argument is opposite to the sense of the method name, but at this point I don't care much any more as long as the docs are clear enough.

I am overall in favor of that change, but we will need to maintain backward compatibility for at least two version. That means adding back the previous argument name, and checking whether the user sets it manually or not, and raising a deprecation message if the user does.
I am terribly sorry not to have pointed this out earlier and not to have been more active on this. This PR completely slipped out of my mind.

@efiring and @tacaswell - can you comment and approve or decline this API change?

I am not convinced that the work to maintain back compatibility and then the deprecation cycle is worth changing the name.

weak 👎 .

@NelleV. There has been a lot going on, so I did not expect much attention to this PR.

I am getting the sense that this may be too much work for a really trivial change that could probably be solved by documentation. Just for the fun of it, I will add the deprecation in to see if you like it.

I am not in favor of this. If we are going to have a CamelCase cleanup in ticker, it should be done all at once rather than piecemeal. (Whether it will ever be worth doing is debatable.)
The real problem, correctly noted by @madphysicist, is that label_minor() is nonsensical. The solution is to deprecate and remove it. (I doubt it is every used in practice, so I don't think this is a big change.) It's replacement is the labelOnlyBase attribute, which I imagine will end up as a Trait if the Traitlets work goes to completion. It could be a property in the interim, but leaving it as a plain attribute is perfectly adequate and Pythonic.

There seems to be a consensus that this patch is not worth the trouble. I am closing the PR.
@madphysicist sorry about the time it took.

I think under the circumstances that is the only thing to do. Thanks for taking care of it for me.

@madphysicist Just to re-iterate @NelleV , thank you for working on this. Saying no is one of the hard things about maintaining mpl 😞 .