Release Notes¶
Djrill practices semantic versioning. Among other things, this means that minor updates (1.x to 1.y) should always be backwards-compatible, and breaking changes will always increment the major version number (1.x to 2.0).
Upcoming Changes in Djrill 2.0¶
Djrill 2.0 is under development and will include some breaking changes. Although the changes won’t impact most Djrill users, the current version of Djrill (1.4) will try to warn you if you use things that will change. (Warnings appear in the console when running Django in debug mode.)
Djrill Admin site
Djrill 2.0 will remove the custom Djrill admin site. It duplicates information from Mandrill’s dashboard, most Djrill users are unaware it exists, and it has caused problems tracking Django admin changes.
Drill 1.4 will report a DeprecationWarning when you try to load
the DjrillAdminSite
. You should remove it from your code.
Also, if you changed Django’s INSTALLED_APPS
setting to use
'django.contrib.admin.apps.SimpleAdminConfig'
, you may be able to
switch that back to 'django.contrib.admin'
and let Django
handle the admin.autodiscover() for you.
Dates in merge data and other attributes
Djrill automatically converts send_at
date and datetime
values to the ISO 8601 string format expected by the Mandrill API.
Unintentionally, it also converts dates used in other Mandrill message
attributes (such as merge_vars
or metadata
) where it
might not be expected (or appropriate).
Djrill 2.0 will remove this automatic date formatting, except
for attributes that are inherently dates (currently only send_at
).
To assist in detecting code relying on the (undocumented) current
behavior, Djrill 1.4 will report a DeprecationWarning for date
or datetime values used in any Mandrill message attributes other
than send_at
. See Formatting Merge Data for other options.
DjrillMessage class
The DjrillMessage
class has not been needed since Djrill 0.2.
You can simply set Djrill message attributes on any Django
EmailMessage
object.
Djrill 1.4 will report a DeprecationWarning if you are still
using DjrillMessage.
DjrillBackendHTTPError
The DjrillBackendHTTPError
exception was replaced in Djrill 0.3
with djrill.MandrillAPIError
. Djrill 1.4 will report a
DeprecationWarning if you are still importing DjrillBackendHTTPError.
Change Log¶
Version 1.4:
- Django 1.8 support
- Support new Django 1.8 EmailMessage reply_to param. (Specifying a Reply-To header still works, with any version of Django, and will override the reply_to param if you use both.)
- Include Mandrill error response in str(MandrillAPIError), to make errors easier to understand.
- More-helpful exception when using a non-JSON-serializable type in merge_vars and other Djrill message attributes
- Deprecation warnings for upcoming 2.0 changes (see above)
Version 1.3:
- Use Mandrill secure https API endpoint (rather than http).
- Support
merge_language
option (for choosing between Handlebars and Mailchimp templates).
Version 1.2:
- Support Django 1.7; add testing on Python 3.3, 3.4, and PyPy
- Bug fixes
Version 1.1:
- Allow use of Mandrill template default “from” and “subject” fields,
via
use_template_from
anduse_template_subject
. - Fix
UnicodeEncodeError
with unicode attachments
Version 1.0:
- Global
MANDRILL_SUBACCOUNT
setting
Version 0.9:
- Better handling for “cc” and “bcc” recipients.
- Allow all extra message headers in send. (Mandrill has relaxed previous API restrictions on headers.)
Version 0.8:
- Expose Mandrill Response on sent messages
Version 0.7:
- Support for Mandrill send options
async
,important
,ip_pool
,return_path_domain
,send_at
,subaccount
, andview_content_link
Version 0.6:
- Support for signed webhooks
Version 0.5:
- Support for incoming mail and other Mandrill webhooks
- Support for Mandrill send options
auto_html
,tracking_domain
andsigning_domain
.
Version 0.4:
- Attachments with a Content-ID are now treated as embedded images
- New Mandrill
inline_css
option is supported - Remove limitations on attachment types, to track Mandrill change
- Documentation is now available on djrill.readthedocs.org
Version 0.3:
- Attachments are now supported
- Mandrill templates are now supported
- A bcc address is now passed to Mandrill as bcc, rather than being lumped in with the “to” recipients. Multiple bcc recipients will now raise an exception, as Mandrill only allows one.
- Python 3 support (with Django 1.5)
- Exceptions should be more useful:
djrill.NotSupportedByMandrillError
replaces generic ValueError;djrill.MandrillAPIError
replaces DjrillBackendHTTPError, and is now derived from requests.HTTPError. (New exceptions are backwards compatible with old ones for existing code.)
Version 0.2:
MANDRILL_API_URL
is no longer required in settings.py- Earlier versions of Djrill required use of a
DjrillMessage
class to specify Mandrill-specific options. This is no longer needed – Mandrill options can now be set directly on a DjangoEmailMessage
object or any subclass. (Existing code can continue to useDjrillMessage
.)