again - please show me those changes! -- Ronny
2018-03-20 19:33 GMT+01:00 Florian Schulze <florian.schu...@gmx.net>: > On 20 Mar 2018, at 16:11, Ronny Pfannschmidt wrote: > > just a quick note - the markers pr as far as i understood it does not >> qualify for a 4.0 since the basci apis are bckward compatible and work as >> expected, if we would make it 4.0 worthy, then by dropping the old cruft >> > > In my opinion the change in transfer behaviour makes it 4.0, because it > *will* affect people. It changed things in devpi-server which necessitates > (small) changes. For others it might have way more far reaching effects. > > Regards, > Florian Schulze > > > 2018-03-20 16:03 GMT+01:00 Florian Schulze <florian.schu...@gmx.net>: >> >> On 20 Mar 2018, at 15:07, Floris Bruynooghe wrote: >>> >>> On Tue, Mar 20 2018, Ronny Pfannschmidt wrote: >>> >>>> >>>> 2018-03-20 9:18 GMT+01:00 Floris Bruynooghe <f...@devork.be>: >>>> >>>>> >>>>> On Mon, Mar 19 2018, Ronny Pfannschmidt wrote: >>>>>> >>>>>> I also did deprecate markinfo attributes, >>>>>>> so everyone using them will get deprecation warnings. >>>>>>> >>>>>>> >>>>>> That's a lot of people probably. How long are we giving users for >>>>>> this? >>>>>> >>>>>> >>>>>> >>>>>> the support for accessing them can be kept for quite a while, >>>>> everyone using them will be told to use the new api >>>>> i would like to remove it at the beginning of 2019 >>>>> >>>>> >>>> Ok, they're currently marked as "deprecated in 4.0". So we're not >>>> releasing 4.0 until then? Or are we just keeping our options open here >>>> and extending a deprecation is easier then reducing it? >>>> >>>> >>> I think the marker PR already qualifies for a 4.0, so I would extend the >>> deprecations. >>> >>> >>> Thanks! Could you give an example of a marker transfer bug? I've never >>> >>>> run into those myself so I'm not sure I understand what this is. >>>> >>>> >>> In devpi-server we have test classes that inherit from another test >>> class. >>> The derived one overwrites one fixture (for example testing through nginx >>> or a devpi replica instead of directly against devpi-server). Because >>> some >>> of these fixtures are expensive, I want to mark the inherited class as >>> "slow". Currently that mark is transferred to the base class and there is >>> no other way to mark only the test functions on the derived class as >>> slow. >>> So currently the base class is also marked as slow. The PR fixes that. >>> >>> Regards, >>> Florian Schulze >>> >>> >> >> >> -- >> >> Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, >> Commercial register: Amtsgericht Muenchen, HRB 153243, >> Managing Directors: Charles Cachera, Michael Cunningham, Michael >> O'Neill, Eric Shander >> > > > -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
