[MAINT] - Improve release process

[soapy1]

Context

Currently the release process for conda-store has a lot of manual tasks. It would be nice to automate some of the manual steps so that the release process is more streamlined. An ideal release process might looks something like

1. check out the main branch, build and test locally
2. create a tag in github for the release

Here, step 2 should do:

• all the required version bumping for conda-store
• pull the latest version number for conda-store-ui
• run the automated tests
• build and push all the relevant artifacts

Value and/or benefit

Makes cutting a release take less engineering time

Anything else?

No response

[peytondmurray]

all the required version bumping for conda-store

I'd vote for either hatch-vcs or setuptools_scm for versioning. Manually setting version strings is both unnecessary and is a recipe for human error, since they are tied precisely to the git tag we have most recently released. I know others feel differently about this, but I haven't yet been convinced that there's a reason not to use automated versioning.

In the release issue template for conda-store, there's a note about needing to make another PR to bump the conda-store and conda-store-server versions to the next dev-release number. This will not be needed if we use automated versioning.

---

We should also have a workflow that triggers on successful release publication which bumps the conda-store-server version in the conda-store-ui compose file.

[trallard]

While I am generally in favour of automating redundant manual steps I am -1 on fully automating the release of conda-store since I do not believe we have good enough confidence or coverage (not only of unit tests but also functional and integration tests) on our test suite and QA processes.

Here, step 2 should do:

all the required version bumping for conda-store

I started working on this in #861, though I did not complete this as I had to shift to other more urgent tasks and fixes.
TBH, some of the complexity comes from the fact that we are necessarily maintaining and releasing two packages. So, IMO, we should work on #911. This will reduce some of the maintenance and release toil (we use this as a mono repo and are separating the CLI from the API unnecessarily) and reduce the cognitive load on users.

We could see #861 to the end as this will avoid needing to bump the version to a development one through a PR (which was not being done until recently when I added this step to the release process), and would also fix the currently broken step of releasing dev versions to test-pypi on merge to main.

I'd vote for either hatch-vcs or setuptools_scm for versioning. Manually setting version strings is both unnecessary and is a recipe for human error, since they are tied precisely to the git tag we have most recently released. I know others feel differently about this, but I haven't yet been convinced that there's a reason not to use automated versioning.

This is precisely what such a PR should accomplish but as I mentioned before, this was stalled due to me needing to shift focus to make the most of the limited hours I can devote to conda-store.

pull the latest version number for conda-store-ui

This is something I think we should not automate. We have made broken releases -- as users mostly use conda-store through the UI and the fact that we do not have a robust or complete CLI or Python API -- due to the UI vendoring/integration with the REST API being broken and not being caught or tested through our CI or by the release captain. This leads to a poor end-user experience and additional maintenance toil. As recent as 2024.9.1, where we made a UI release that seemed completely functional and worked on its own, I realised this was not working when vendoring with conda-store-server through manual inspection, which led to several fixes needed on the UI to make a full release of conda-store + a newer version of the UI.

This is why I recently added more manual steps to encourage release captains to verify that the build works (which our CI already does) and that the vendor UI actually works with the current version of conda-store.
I recently added bits to enable using local builds of the UI to encourage and facilitate testing and development with a dev version of the UI. Though there are no tests (integration or functional) that do such a verification right now, these need adding first and should include Playwright (and visual test) to ensure everything is working as expected (since our current tests use the REST API as-is but do not rely on the UI per see).

run the automated tests
build and push all the relevant artifacts

This is already done.