Deprecation policy - insert considerations for breaking changes #6298
Conversation
|
Do you plan to get this into 5.4 or only in the next major release? |
|
@nicoddemus i'd like to get this into 5.4, but enact it starting with 6.0 |
RonnyPfannschmidt
changed the title
|
i'll squash before merging myself |
|
@asottile would you like another look, i'm going to squash soon and go for a merge then |
Co-Authored-By: Anthony Sottile <[email protected]> Co-Authored-By: Bruno Oliveira <[email protected]> Co-Authored-By: Hugo van Kemenade <[email protected]>
RonnyPfannschmidt
force-pushed
the
deprecation-breakage
branch
from
7d64f7f to
3812985
Compare
RonnyPfannschmidt
changed the title
|
thanks everyone for chiming in and helping out to make this one nice 👍 |
|
I think we should announce this somehow, would you like to post this on Twitter @RonnyPfannschmidt? |
|
I just realized this went to |
|
It's intentionally there, the next and possible last feature branch feature release is close |
|
Cool. Btw can your review your action items for 6.0? I suspect the ones there created by you won't be ready for 6.0 and will need to be postponed. |
|
Will take a look after travel |
we have a number of structural changes ahead in Node Structure, fixture internals, as well as many other detail api's
as such i wanted to propose a update to our deprecation policy that enables sorting those out in a coordinated way when transitional apis are not sustainable.