Deprecation policy - insert considerations for breaking changes#6298
Conversation
nicoddemus
left a comment
nicoddemus
left a comment
There was a problem hiding this comment.
Cool, thanks for putting this together @RonnyPfannschmidt!
|
Do you plan to get this into 5.4 or only in the next major release? |
asottile
left a comment
asottile
left a comment
There was a problem hiding this comment.
overall looks good -- I'll take a second pass after more of the other reviews have been settled (I had a hard time reading it without being distracted hehe)
|
@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 <asottile@umich.edu> Co-Authored-By: Bruno Oliveira <nicoddemus@gmail.com> Co-Authored-By: Hugo van Kemenade <hugovk@users.noreply.github.com>
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 |
4 participants
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.