[pytest-dev] mark fix-up major milestone, please review

[Ronny Pfannschmidt]

again - please show me those changes!

-- Ronny

2018-03-20 19:33 GMT+01:00 Florian Schulze <florian.schulze at 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.schulze at 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 <flub at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pytest-dev/attachments/20180320/63ed92fc/attachment-0001.html>