Release process - feedback request

[Kriti Godey]

Hi everyone,

I've created a draft of the release process on the wiki: https://wiki.mathesar.org/en/product/release-process

I'd like feedback ASAP from Brent, Pavish, Mukesh, and Dom.

I did not test the Docker commands. Please double check them.

Thanks!

Kriti

[Pavish Kumar Ramani Gopal]

The draft looks good to me. The commands also look good.

I have a question for the backend team for this point from the draft:

> Also update the version number in install.sh if needed.

I do see a `github_tag` variable in the script to identify which branch/tag to download the `docker-compose.yml` file from. But the compose file always points to the image with the latest tag. So, I don't find the variable being of any actual use at the moment. Is this assumption correct?

Eventually, I'd like to be able to install a specific version via the quick start command, which points to the `install.sh` and `docker-compose.yml` files from the specified branch/tag, and the docker-compose.yml file inturn pointing to the image tagged with the same version. I understand we did not do that because watchtower always points to the latest tag and that would affect upgrades, but I'm sure we can find ways around that (by adding a command in install.sh to locally tag the downloaded image as latest).

[Dominykas Mostauskis]

Pre-release steps 3 and 4 set the tag and compile the release notes. I like the idea of doing this before starting the release process, but Github's release UI automates large parts of these tasks: https://github.com/centerofci/mathesar/releases/new

It has some tag controls, where you can have it create a tag on release (or use an existing tag), and there's some functionality for automatically adding closed issues to the release notes. You can also mark a release as a pre-release (that will make it so that, for example, the release doesn't show up when querying for the latest release (pre-releases are filtered out), you can also save it as a draft (we probably can collaborate on draft releases).

I suggest:

- we create the release tag in the GH release UI,

- we compile essential release notes copy outside the GH release UI, but then use the UI to add the fixed issues list to the release notes.

[Mukesh Murali]

The draft looks good to me.

> So, I don't find the variable being of any actual use at the moment. Is this assumption correct?

Yes, the assumption is correct. For now, the release process is valid only to upgrade mathesar to the latest version and not for installing a specific version. 

[Kriti Godey]

The release notes are now finalized. https://wiki.mathesar.org/en/product/release-process. Brent has made changes to it, and I incorporated some of Dom's feedback (creating a tag is still separate, since it helps us identify the commit for Docker images). We can update the process for future releases (I'd like to automate most of this).