Switch template to calendar versioning

Description

The template is currently versioned after the version of Django it uses:

https://github.com/pydanny/cookiecutter-django/blob/b48067c03494993933bd2eb0aa2e5afdf367f12f/setup.py#L11-L13

I suggest changing this to calendar versioning instead e.g. 2021.1.24

Rationale

With Github actions, we’ve been able to automate a few things around the project management:

1. Drafting Github releases thanks to release drafter
2. Generating Changelog with a custom script that we run every night.

However, this approach has a few issues:

• Changelog file and release changes are not consistent, they 2 different views of the same thing.
• The Github release doesn’t tell much about when changes were actually usable, one typically uses the latest in master when calling the cookiecutter CLI.
• The changelog script might need some maintenance down the road, would be nicer to rely on a community supported Github action.
• Changing the version template is not automated yet, and we often miss the step when the version of Django is updated.

Solution

Ideally we would use off the shelf action(s) like:

• https://github.com/fregante/daily-version-action
• https://github.com/notlmn/release-with-changelog

These are providing some building pieces. Ideally, we also need one to keep the changelog file up to date.

Would be nice to find an all in one solution, an equivalent of https://github.com/relekang/python-semantic-release, but for calendar base releases.

This process would run like the current update changelog script, every night on schedule.

[browniebroke]

Yes, pretty much. That’s been working pretty well for generating our CHANGELOG.md. We do so every day at 2 AM (UTC):

https://github.com/pydanny/cookiecutter-django/blob/34ad90bdd83a9e771c3cca801b00b02ad6b8991d/.github/workflows/update-changelog.yml#L4-L6

The script we run iterate through the pull requests from the day before:

https://github.com/pydanny/cookiecutter-django/blob/34ad90bdd83a9e771c3cca801b00b02ad6b8991d/scripts/update_changelog.py#L11-L12

In case it fails for an external reason and needs to retried (that happened once AFAIR), we can trigger it manually, and we have the whole day to do so:

https://github.com/pydanny/cookiecutter-django/blob/34ad90bdd83a9e771c3cca801b00b02ad6b8991d/.github/workflows/update-changelog.yml#L7-L8

[Andrew-Chen-Wang]

Right. So maybe using datetime to get the current UTC date, then release at the end of greenwich time for a day in case a PR was merged? That’d make the most sense to me.