Consider making automatic tags/releases

[steven-murray]

Currently we have an action to create a PyPI release whenever a new version is tagged via git/Github. We can potentially go further than this and auto-tag using an action: https://github.com/mathieudutour/github-tag-action.

The brief summary of the action is that it will analyze all commit messages since the last merge to master, and based on the AngularJS commit convention, it will decide whether the MAJOR, MINOR or PATCH version number should be increased. It will thus create a tag on the repo, which will trigger PyPI to create a new release.

The pros:

• Hands-off approach to versioning and releasing.
• As long as commit messages are formatted correctly, semantic versioning is maintained more consistently than having someone "decide" on what version number to update.
• Having to stick to commit conventions is probably a good thing in the long term.

The cons:

• Developers need to stick to AngularJS commit conventions, which could discourage new developers a bit.
• Requires maintaining strict semantic version (I think this is a good idea, but various opinions may exist, see below).
• Can be a bit trickier to "bundle" changes, since every merge to master that has a change that triggers a version change will cause an update. Clearly, bundling some changes is a good idea. This can be gotten around by having a set branch where changes for a new version can be accumulated before merging to master.
• I'm not sure how to deal with the changelog exactly. Automated schemes for this exist, based on commit messages, but I haven't used them.

The one thing that definitely makes this a no-go is not having semantic versioning. Here's the current description of versioning for pyuvdata:

We use a generation.major.minor version number format. We use the generation number for very significant improvements or major rewrites, the major number to indicate substantial package changes (intended to be released every 3-4 months) and the minor number to release smaller incremental updates (intended to be released approximately monthly and which usually do not include breaking API changes). We do our best to provide a significant period (usually 2 major generations) of deprecation warnings for all breaking changes to the API. We track all changes in our changelog.

Essentially, this description makes no guarantee that even minor versions won't have breaking changes. Essentially, it seems like it is more of a time-based release strategy than a semantic one. Time-based strategies make some sense for programs, but not usually for libraries that other codes depend on. For libraries, semantic versioning is typically the suggested scheme. Its definition/motivation is here: https://semver.org/.

In brief, it offers guarantees for code that depends on pyuvdata for when pyuvdata may be updated to break their code. In early stages of development, it doesn't work as well since you might end up at v10 before settling on a good API (although, there's also nothing inherently wrong with that...). But since pyuvdata is rather mature now, we could certainly think about adopting this standard which is really becoming a standard.