Unit vs Slave

[mkbrewer]

This is a follow up on issue #1059. I too ran into this problem. In my case, the solution was relatively simple as I am using Version 2.5.3 and the RTD for that version clearly states that unit should be used. When a major breaking change like this is made to the API, at the very least, the version number should be bumped and the changelog should note the change and give a list of methods or classes for which the change applies. With a change this major, I would also suggest adding a note:: to the docstrings of the classes affected to the effect that before version X, the slave parameter was unit instead.

[janiversen]

The version number was changed to 3.0 and the doc. clearly states where to use what, but it does not help when people look at doc in on version but loads another version.

[janiversen]

Pull requests are welcome if you want changes.

[janiversen]

Closing as already done.

[mkbrewer]

Well, anyone who installed Version 3 before PR #1056 is affected by this, so, at the very least, a new changlog entry should have accompanied that PR.

[janiversen]

That is not true, the latest prerelease 3.0.0dev4 works as 2.5.3, anyone who forks the repo (with documentation) must use slave= as the supplied documentation states.

Jumping to 3.0 is because there are major changes in the API, slave= or unit= is one of the smaller changes.

But as I wrote earlier patches are welcome.

[janiversen]

Changelog.rst are generated when you make a release not for every commit on dev. Once we make 3.0.0dev5 the changelog will be updated.