Tags numbering for release versions

[amakarudze]

We are introducing automated deployment that will be triggered by releases. So far despite upgrading the Django versions and adding translations or new features, our release has been stuck at v1.0.0. There is work to upgrade to Django version > 4.0 currently underway. Am wondering for the first release, should this be a minor one v1.1.0 or major v2.0.0 since there have been major changes to the repo over the last year.

I have already merged in #858 but need to create a release for this to be triggered and work.

@marksweb what do you think?

[marksweb]

I do like 3 digit version numbers and try to follow semver when using this format of versioning.

It can work well and I consider changes to version numbers based on these kind of changes;

• Change the major (first number) - major changes like upgrading django to new major version or python
• Change the minor (second number) - feature releases
• Change the patch (third number) - minor changes like templates, bug fixes or styling tweaks

Deciding on the version change required would come as part of the release process where you can assess the changes to be released. A side note here - github releases can auto-generate a change list. When you prepare a new tag a button becomes available to generate changes since the last tag.

It's also worth considering that this version format doesn't always work for web site projects because it might lack meaning. Sometimes a version number based on dates could work better - perhaps the date of each release could be the version number.

[amakarudze]

Thanks @marksweb. That's really helpful. I have done two automatic deployments so far. The very first one didn't work because I had put public key instead of the private key for SSH. I have now fixed the keys and no longer have to log in to PythonAnywhere to deploy. Thanks for your help with this and thanks to @vanessa for suggesting this.

[marksweb]

Fantastic news!

[ramonsaraiva]

I like semver as well!