[pytest-dev] the potential need to release 4.0 instead of 3.1, proposal

[Oliver Bestwalter]

Hi all,

this is a bit meta, as I have not enough insight about the topic at hand (I
did not follow the discussion closely), but as the one who proposed the
policy at the last sprint, I feel obliged to give my two cents about that
aspect of the discussion. I also try to give my perspective as a pytest
user.

At the last sprint I tried to find a solution to a problem that I
repeatedly noticed during conversations at last years' sprint. There were a
lot of corners in the code where things should be tidied up but can't,
because of backwards compatibility concerns. I wanted to start a discussion
how to be able to break backwards compatibility in an acceptable way for
users, by giving them (on by default) deprecation warnings and having a
clear exit strategy. What I did not want is to introduce unnecessary
friction into the development process. So if it turns out that this is the
case and breaking backwards compatibility is better handled on a case by
case basis in pytest, just revoke the policy and declare it a failed
experiment. No harm done. If it is thought that the policy as basically not
a bad thing but needs tweaking, please let's do that, I am happy to help.

As a user of testing tools like pytest, tox, devpi, coverage, flexmock and
whatnot, I personally do not mind if my CI dependencies break now and then
anyway. If I come into the office in the morning and our CI monitor is an
ocean of red nightly builds, I know that a dependency has broken and I can
deal with it accordingly (e.g. pinning the version until I have adapted my
code or the dependency has been fixed). I think that is just a normal
aspect of being part of a vibrant ecosystem.

Also: maybe some internal changes that break backwards compatibility in a
way that you can't even give proper warnings (like it seems to be the case
with this change ... I am not sure though as I did not understand the
change properly). Then the policy doesn't really apply and it has to be
handled differently (a foolish consistency is the hobgoblin of little minds
after all). The users should then be informed why this happens the way it
does (and why a longer lead up and a major release is not justified
although some backwards compatibility might break). This would still be
perfectly o.k. for me as user. We all sometimes make promises, we can't
keep after all ...

As an aside: here is what happened with the last requests release and how
they handled it: https://github.com/kennethreitz/requests/issues/4006).

Last word from a happy FLOSS user: what always outweighs the pain of broken
things for me is my gratitude towards all the voluntary work that flows
into the libraries and tools that I can use in my daily life instead of
being stuck with prorietary cr***. It's not like somebody dies because my
testing framework broke my CI builds, so I always try to keep things in
perspective :)

Cheers,
Oliver

On Sun, 21 May 2017 at 13:28 Floris Bruynooghe <flub at devork.be> wrote:

> Ronny Pfannschmidt <opensource at ronnypfannschmidt.de> writes:
> > 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,
>
> What we can do according to our policy is saying in our documentation
> and announcements: in two releases time we'll break this backwards
> compatibility thing (whether that's new-style classes or marks).  Then
> two releases later bump the major version and do it.  It slows breakage
> a little bit down and I thought that was the reason for the current
> deprecation policy.  Yes it is more annoying as we basically have to
> leave a pull-request or branch lying around for all that time and deal
> with the merging breakage resulting from this.
>
> Having said that, I'm happy to re-evaluate the policy if enough people
> think this is a bad idea.  But I'd like some user feedback as well
> before changing it.
>
>
> Floris
> _______________________________________________
> pytest-dev mailing list
> pytest-dev at python.org
> https://mail.python.org/mailman/listinfo/pytest-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20170521/41a4f4ab/attachment.html>