Update domain to brevo.com

[sblondon]

Sendinblue change its name to Brevo (https://www.brevo.com/blog/becoming-brevo/). The API is also available on the new domain. The previous one still works, so there is no emergency to patch and release.

This is a minimal change to update but I guess it would be better:

• to have a new backend brevo.EmailBackend with the implementation.
• sendinblue.EmailBackend would inherit brevo.EmailBackend to use the same URL but adding such warning:

warnings.warn("Sendinblue has renamed itself Brevo. Change to Brevo backend.", DeprecationWarning)

What do you think about it?

[medmunds]

Thanks for this.

My inclination is to:

• Update the API url (as you've done here)
• Update the documentation to refer to "Brevo (formerly Sendinblue)", and update any links in the docs to point to Brevo
• Update the readme, project keywords, etc. to include "Brevo"
• Not change the ESP name in the code

Propagating Sendinblue's rebranding throughout Anymail's code would change more than just the EMAIL_BACKEND path—it would also affect settings names, webhook urls, the esp_name parameter to signals, and probably some other things I'm forgetting. That seems like a lot of churn for Anymail's users, without any functional benefit.

This would match what we did with MailChimp Transactional, which used to be called "Mandrill"—and still is throughout Anymail's code.

(I'm open to counter-arguments, particularly if you're volunteering to do the work. But it might be better to move that conversation to the Discussions.)

[sblondon]

@medmunds Thanks for your feedback. I agree with your opinion. I will implement it.

[sblondon]

@medmunds Replacing and reordering 'Sendinblue' to 'Brevo' in documentation is done.

Things I did not change:

• I did not change occurences in CHANGELOG.rst file. I think it would be better to add a line about Brevo rebranding in the file for the next release.
• I wonder if it's a good idea to rename tests/{test_sendinblue_backend.py,test_sendinblue_integration.py,test_sendinblue_webhooks.py}. On one side, the name is now Brevo but on the other side, the file is still backends/sendinblue.py. I would go to not rename them because it's probably more obvious if someone wants to implement or fix something in the django-anymail library.
• I did not change SENDINBLUE_API_KEY to avoid breaking change. I think it matches with the idea to not change the name of the backend currently.
• I did not change the sendinblue.rst to brevo.rst so the links on the web pointing to this page will not break. However, the link label is 'Brevo' and the URL contains 'sendinblue'. I think it could be changed.

What do you think about these 4 items?

[medmunds]

Outstanding, thanks!

I did not change occurences in CHANGELOG.rst file. I think it would be better to add a line about Brevo rebranding in the file for the next release.

Agreed.

I wonder if it's a good idea to rename tests/{test_sendinblue_backend.py,test_sendinblue_integration.py,test_sendinblue_webhooks.py}. ... I would go to not rename them

Agreed, leave the test filenames "sendinblue" to match the implementation filenames.

I did not change SENDINBLUE_API_KEY to avoid breaking change. I think it matches with the idea to not change the name of the backend currently.

Agreed.

I did not change the sendinblue.rst to brevo.rst so the links on the web pointing to this page will not break. However, the link label is 'Brevo' and the URL contains 'sendinblue'. I think it could be changed.

Yes, please rename the docs file. (That will also keep the list alphabetical in esps/index.rst.)

I will set up ReadTheDocs page redirects to keep links from breaking.

[sblondon]

The sendinblue.rst file is renamed (and index.rst is modified to fit the renaming).

I sent myself an e-mail with the last commit as library in a virtualenv (with git+https://github.com/sblondon/django-anymail.git@a26cdb5896a360d39630d4c090196bef2f39c764) and received it.

Do you think about other required modifications?

[medmunds]

This looks great. I updated the changelog and project keywords, and fixed a couple of minor things in the docs. (Also took the opportunity to deemphasize some older Sendinblue template compatibility stuff.)

I think it's ready to merge. Thanks again!