MAILGUN_SERVER_NAME unused?

[phiberjenz]

Where is the env MAILGUN_SERVER_NAME used?

I can only find it in the env.example file and also in the "Deploy to PythonAnywhere/Heroku" and "Settings" part of the documentation.

It seems that it's not used anywhere in the code.

Is there a reason for having this env?

[yunti]

It might be a hangover before things were switched to Django-anymail

[Afrowave]

It is the default mail engine that one can use. You would register the domain to use at mailgun.com. In the config/production.py, one would use Anymail with Mailgun like so:

# Anymail
ANYMAIL = {
    "MAILGUN_API_KEY": "env('DJANGO_MAILGUN_API_KEY')",
}
ANYMAIL["MAILGUN_API_KEY"] = env('DJANGO_MAILGUN_API_KEY')
EMAIL_BACKEND = "anymail.backends.mailgun.MailgunBackend"

DEFAULT_FROM_EMAIL = "postmaster@your-domain.com"

The DEFAULT_FROM_EMAIL is for you to configure to the email you would want to use.
The other mail backends may be found at django-anymail.

And the your .env file:

DJANGO_MAILGUN_API_KEY=key-fill-in-your-keycode-here
DJANGO_MAILGUN_SERVER_NAME=https://api.mailgun.net/v3/your-domain.com
DJANGO_SERVER_EMAIL=postmaster@your-domain.com

[ssteinerx]

It might be a hangover before things were switched to Django-anymail

The version numbering scheme of this project has a unique constraint in that it is tied to a particular Django release, so sticking with strict semver seems a bit counter-intuitive.

How can you follow the semver rules when 1.8.x, 1.9.x, 1.10.x are all "Version 1.x" but each "1.x" version, by definition, introduces incompatible changes?

According to the rules, if there was a release leading to a backwards-incompatible change, semver rules should have forced a semver Major Version change:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

One idea would be to switch the version numbering of cookiecutter-django completely so that:

1.8.x => 18.x.x
1.9.x =? 19.x.x
1.10.x => 10.x.x
1.11.x => 11.x.x

The tricky part comes when Django 2.x is released. The rules say we can't just blithely go back to:

2.0.0 => 2.x.x

So, we would have to do something like:

2.0.0 => 20.x.x
2.1.0 => 20.1.x

but we lose a significant digit.

Not sure what the trick is here...maybe someone else has a better idea?

Thanks,
S

[browniebroke]

Fixed in #1545