@tomchristie @rpkilby I quite like this. It adds a small amount of code by makes handling deprecations a lot simpler.

• Branch for 3.10, delete RemovedInDRF310Warning, delete all the code that breaks.
  • Note that for release announcement.
• Bump RemovedInDRF311Warning to DeprecationWarning.
  • Note for release announcement.

Much harder to miss anything.

Let me know what you think. If we're happy with it I'll merge.

Either way, this wraps up 3.9.2 🎉 I'll prepare the release over the weekend. 💃

I'm definitely in favor of this.

@auvipy I think I've asked this before, but please don't use the PR approval unless you're actively involved in a ticket. (As it happens I'd rather it was only enabled for maintainers or by-request-from-maintainers, but GitHub doesn't allow us to turn the functionality off.)

@tomchristie I don't use PR approve button unless I go through it fully. I don't know how you manage to do this in an open source project? respectfully disagree with you on this point.

Hi @auvipy.

To be honest I too find it distracting that you approve PRs without adding to the conversation.

For me it would be better if you spent your time looking at less PRs but reviewed them fully, with comments and improvements etc. There’s a massive backlog around the ecosystem so plenty to do there.

Then if there were some PRs that you just approved that would tell something. As it stands it your tick isn’t often acting as a marker, since it’s too quickly given, so it’s not serving as a guide as to whether to merge.

I hope that makes sense. It’s meant in a spirit of love and encouragement. Please think about it. Happy to chat off thread if you like. C.

@carltongibson I would really love to engage that way. I get paid for working with foss. so why not :)

@auvipy OK, send me an email. 👍

definitely, I will. you just won my heart by your words Carlton <3