General Update for 2022 and dynamic dev version support

[Cadair]

This is a continuation of #13 with some further cleanup.

Fixes #1 by docs Fixes #19

---

Questions to answer before merge:

1. Do we want setuptools_scm to be optional (it isn't at the moment).
 - Guide yes, template no.
2. If yes what do we want the default to be
 - N/A
3. Do we want _dev to be optional? - Yes

[nabobalis]

Some beautiful changes, you should thank the person who started the ball on this.

👍

[bsipocz]

Do we want setuptools_scm to be optional (it isn't at the moment).


not having it would mean that we can have a reasonable dev version number without the awkward tagging after a release, right? If yes, then also I would go with "no" for q2

[Cadair]

without the awkward tagging after a release

Well that's a "feature" of tagging on release branches. I think that minor annoyance is worth the general helpfulness of not having to manually maintain a version number.

I would point out at this point that this is supposed to be an opinionated template & guide, everything in the template should be documented and we want the documentation to be easy to follow.

The only middle ground we could do is have a hidden option which defaults to on, so downstream templates could optionally turn it off, although I would rather not do that either. If it's worth having then it's worth having on by default and documenting.

[bsipocz]

Well, opinions differ then what is convenient, while this workflow can work for large libraries, I would not want to do this dev tagging for a frequently released package where releases are done from the default branch. (and dev tagging is basically just as manual than any other way to bump the version number)

[Cadair]

where releases are done from the default branch

You don't have to do it in this case, you only have to dev tag if you put your release tags on the not default branch.

[Cadair]

Well I am close. The tests pass locally for me but here I get some insane virtualenv error :sob: