(sending again due to prior sender typo)

given the rightfully reasserted constraints that seems a reasonable
course of action,

i'd prefer to keep it reopened instead of won't fix,
and i'd like to see a revising of the deprecation policy,

since as things as
https://github.com/pytest-dev/pytest/labels/mark-issue are impossible to
fix without being able to break things in a sensible way (its just too
much of a mess)

-- Ronny
Am 18.05.2017 um 22:05 schrieb Bruno Oliveira:
>
>
> On Thu, May 18, 2017 at 2:25 PM Floris Bruynooghe <[email protected]
> <mailto:[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

_______________________________________________
pytest-dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/pytest-dev

Reply via email to