Simplify contribution and release workflow (drop dev branch)

[shum23]

We've been thinking about whether the current main + dev protocol is still the most sensible way for contribution and release, and whether migrating to a more streamlined workflow would lower friction for contributors. The current protocol has worked well but as the contributor base grows we've noticed some recurring friction worth addressing. Posting here to gather thoughts first.

Current protocol

• main tracks the latest stable release on pypi; untouched until a dedicated release branch is merged in.
• dev is where features and fixes land; contributors branch off dev and PR back into dev. A release branch is then made from dev.
• docs build on merges into both dev and main, corresponding to 'latest' and version numbers in the docs switcher.
• releases are published to pypi on tagged versions.

Potential new workflow

• A single branch main. Feature/fix branches off main and PR back into main.
• Directly tagging a version to release it without a dedicated release branch: sort out version number and changelog --> tag it with x.y.z -> release -> bump the main version to e.g. x.y.(z+1).dev for a patch release
• pypi publishing on tags stays as-is
• To test a big release we can still tag e.g. x.y.zrc1 to trigger a pre-release on pypi

Reasoning

• The current releasing pattern of 'branch off from dev --> bump release version --> merge release into main --> back-merge main into dev --> bump dev version' includes multiple merges and is a bit back-and-forth and easy to get wrong (e.g. accidental divergence between branches) and adds friction to maintenance
• Contributors always need to change the merge target from main to dev and this option is not editable once the PR has been raised. A single source is clear and lowers the barrier to entry for new contributors.
• Closing keywords in PRs don't work effectively when a PR gets merged into dev because auto-closing only works for the default branch (main). Manual closing is often needed.
• Stability is already guarded by tags and pypi releases; main/dev split seems to duplicate it. And installing from source still works fine by appending a tag
• It seems more modern - the broader ecosystem has adopted this pattern, e.g. xarray, numpy.

Migration

• Merge the current dev branch into main and delete dev
• Update the docs - note in the changelog that any pip install git+<repo>@dev workflows will break. Update the installation instructions and contributing guide

Open questions

• Does anyone rely on installing from dev?
• dev vs dev0 (dev plus an incremental number) for the dev version suffix?
• Anything I've missed that would break things?

[phrgab]

Thanks @shum23

I think moving to just having a main branch as the latest (potentially unstable) branch is probably cleaner here. I think this would simplify both the release and the contribution overhead. People can still install from source using a tagged version to get a stable release.

We can make temporary release branches while preparing the release as required still. Then if we e.g. want to release only a subset of commits that is currently on main, we can always tag the release branch if required? I think it would be good if we can automate as much of the release cycle as possible too...

[shum23]

Thanks @phrgab. I've updated the installation instructions and contributing guide there in #37. I suggest that once everything is ready, we merge it all into main, bin dev and then release v0.5.1. Re. automation, I don't think we need to figure out the full workflow in one go. We can look into that a bit later.