Hi everyone, I'm also fine to discuss changes to our deprecation policy as Ronny is suggesting.
Cheers, Bruon On Mon, Nov 25, 2019 at 12:02 PM Bruno Oliveira <nicodde...@gmail.com> wrote: > Hi Ronny, > > Thanks for writing up. > > Personally I'm tired of arguing for having the "features" branch around, > which most core devs think it is not necessary, so I'm OK with us dropping > it and just having a `master` branch, with each release being potentially a > bugfix or a feature release. > > Cheers, > Bruno > > On Sun, Nov 24, 2019 at 7:36 PM RonnyPfannschmidt < > opensou...@ronnypfannschmidt.de> wrote: > >> Hi everyone, >> >> in the last few months i have tried to find a way to work with/around >> our deprecation policy while detangleing Nodes (and something similar >> will be required for fixtures as well). >> >> This process has been rather frustrating and time-eating so far, >> additionally the changes (like for example node-from-parent) do not >> nearly deliver as much value as i hoped it would. >> >> For me personally i arrived at the conclusion, that if the current >> deprecation policy stays, >> its no longer reasonable for me to spend time on trying to restructure >> the entangled internals of pytest. >> >> In addition, even when attempting to iterate this in small breaking >> increments, >> its abysmally ineffective from a feedback loop standpoint to have the >> feature branch gate such changes for longer time-frames. >> >> As such i want to request that we enable pushing for "reasonably sized" >> breaking changes way more often. >> >> (where reasonably sized means touches exposed internals/structure in >> such a way that it wont affect normal users, but might affect plugins >> that are deeply involved) >> >> (examples of this are dropping support for the config/session parameters >> for node constructors, changing the behavior of the node-id creation, >> changing the config object initialization lifecycle/state management). >> >> >> And additionally i want to request dropping the feature branch mechanism >> in order to get a much tighter feedback loop on the changes going in. >> >> >> -- Ronny >> >> _______________________________________________ >> pytest-dev mailing list >> pytest-dev@python.org >> https://mail.python.org/mailman/listinfo/pytest-dev >> >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
