Release workflow

[TeresiaOlsson]

What is our current release workflow? I discovered that at least some of the problems the CLS colleagues have with the examples are because the latest release was done on 23 January and there were many bug fixes done between then and the workshop which was never included in the release.

So I tried to make a new release myself by adding a tag for 0.2.4 and push it. Turns out that it isn't sufficient because of issue #204 so version numbers are not automatically read from git tags but I have to manually also change in the __init__ file. That already doesn't feel so convenient but now I'm also stuck because I can't push this change to the main branch. Do I really have to make a new branch, update the version number, make a merge request and wait for someone to approve before the release can be made? It didn't look like that is the procedure when I checked in the git history to understand what @gupichon had to do last time a release was made?

[gubaidulinvadim]

I think it is a limitation of Hatch that there's no automatic versioning for a patch a.b.{PATCH}, which I think is done for poetry releases. There are ways to overcome this, I think. For a tag, yes if you need to make a version in init, you'd need to create a branch and merge it. The main branch is protected, and I think it is normal that someone should approve the release of a new version. This merge request is also an opportunity to make release notes and list of changes. After merge, you tag the new version for CI/CD. This is all my assumptions; I didn't check that we've actually set it up this way.

For mbtrack2, we have automatic PATCH versioning on commit, and a minor version number is done in a separate merge request with the list of changes, release notes, etc. But either way is fine.

P.S. Please assign a project to an issue. This way it will appear in the todo section in "Projects".

[TeresiaOlsson]

For me it works both with poetry and uv so if that is the case perhaps hatch is not the best build engine to use? I think it would also be very useful for debugging purposes to add the commit at the end of the version when installing from the git repository. That is done for pyAT and has helped me many times to understand what is going on and which version I actually have installed. For pyaml it's currently confusing because pip list will tell you 0.2.3 independently of if you installed the version that has been tagged 0.2.3 or a commit that has been done after that.

Okay, then next week I will make a separate branch and make a merge request for the release so we hopefully can fix the problems for CLS. I guess in the meantime they can work with the version from the repository because that one I checked and can still run the BESSY II examples without issues. Unless there potentially also is some Mac issue...

[gubaidulinvadim]

@TeresiaOlsson we've updated CONTRIBUTING.md with the release workflow description #211 (review). I think, it is possible to to do with hatch (using some additional tool specified in pyproject.toml) the automatique versioning of patch. But I don't use hatch.

[gubaidulinvadim]

Fixed in #213

[TeresiaOlsson]

I think there is something missing in the release workflow. A release was done on pypi but no new release was added to Github and the changelog was not automatically created. @gupichon How did you do it last time?

[TeresiaOlsson]

Looks to me like we actually don't have anything in our workflows that makes the release on Github? So that part is still manual and need to be added to the workflows?

[TeresiaOlsson]

I added the release on github manually but it should be possible to add it to the workflow since I do it for OPA. I will copy over what I did there when I have time.