On Thu, May 18, 2017 at 2:25 PM Floris Bruynooghe <[email protected]> wrote:
> > My main objection was purely on the fact that we basically disobey the > deprecation policy right after introducing it by doing this. Hmm you are right, I think this is the central point: introducing this change is known to possibly break things, so we should obey our deprecation policy of at least two minor versions before introducing such a change, so it can't get out in the next release regardless if it it is 4.0 or 3.1. If we do > go with Ronny's approach of just bumping the version number when > breaking backwards compat (which is what setuptools and pip and the > like do afaik) then we really should update that policy to reflect so. > I just thought the reason the policy was introduced was because of > user feedback on our earlier behaviour where we usually randomly > justified breakages because it made development more convenient. > To be fair, this change was introduced not because it makes development easier, but because of a user's request ( https://github.com/pytest-dev/pytest/issues/2147): the subtle differences between old style and new style classes can be annoying. Given all we've discussed so far, I think the change in the end is not worth the hassle and the possibility of breaking the API further. My proposal: 1. Drop the new-style class changes (merge #2414). 2. Close the original user request ( https://github.com/pytest-dev/pytest/issues/2147) as "won't fix", detailing the reasons as we discussed here. 3. Release 3.1. \o/ What do you guys say? Ronny? Cheers,
_______________________________________________ pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
