Release tagging mechanics

[pjbull]

For changes to defaults, we'll want well structured release mechanics.

This has come up since #387 is proposing changing defaults.

Here's a proposal for release mechanics:

• Develop feature branches PR'd into master
• Release regularly following semantic versioning
• Couple both ccds code + template changes together in a single version number (maybe we split these out later, but lets keep it simple for now)
• On release workflow, tag commit with version number
• Publish corresponding ccds package version number to PyPI
• Default ccds clones the template @ the version tag
• Add --latest flag to get the latest from master instead

Thoughts?

[chrisjkuch]

I think this sounds quite reasonable to me!

[chrisjkuch]

One additional thought here after thinking about implementation. tl;dr it might be easier to ask people to -c / --checkout master rather than introduce a new --latest option.

Since ccds wraps around cookiecutter, and cookiecutter is a click CLI, it's relatively easy (if, IMO, not super transparent) to change the default values of various options and parameters (as we already do for the template URL) but seems (to me) relatively less trivial to add new options entirely. Rather than introduce a new option, my opinion is that we might want to just ask people to --checkout master if they want the latest, rather than try to add a new CLI option entirely, and to change the default --checkout option value to whatever the current __version__ of ccds is (like how we do for the template URL).

Thoughts @pjbull? From an implementation strategy perspective, I could add this separately or include as part of #336 (which implements the other parts of the requested workflow).

[pjbull]

Seems good to me to just go with what exists, thanks!