Bump version v2.2.0a0 -> v2.2.0a1

[danielhollas]

I want to get a fix in #350 in a new alpha version.

Note, I've specifically opened this PR from my fork, to test @unkcpz observation that the tag from fork will not get transferred to origin when the PR is merged (which is most likely what will happen). In that case, I'll create the tag manually after merge.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.17%. Comparing base (cc4291b) to head (826ad43).
Report is 3 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #585      +/-   ##
==========================================
+ Coverage   87.07%   96.17%   +9.10%     
==========================================
  Files          27       11      -16     
  Lines        4649     1177    -3472     
==========================================
- Hits         4048     1132    -2916     
+ Misses        601       45     -556     

Flag	Coverage Δ
python-3.10	96.17% <ø> (+9.10%)	⬆️
python-3.9	96.17% <ø> (+9.07%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[superstar54]

LGTM!

[danielhollas]

Cheers @superstar54

Indeed, the tag was not transferred from the forked repo, I've created it manually when making a release. It's nice that you can specify a specific commit for the tag.

[unkcpz]

If the tag from the fork is not sync to the repo, then it is meaningless to tag to the forked repo, we need to remove tag = True.

[unkcpz]

It's nice that you can specify a specific commit for the tag.

Now I am confusing again. If the tag has to be create manually, it entirely fallback to the strategy that create the tag to trigger the deployment (upload to PyPI). So in the end, I think we should use create tag to make the release (I think it is also quite standard, no?) What we learned and can added is using this CI review and approve, I don't remember where it is implemented and I am confused why I didn't see it now.

[danielhollas]

Sorry for confusion. I think this is better to discuss in person (unfortunately I will not be able to make it to today's meeting).

tl;dr IMO the solution here is to always push the release branches to origin, and not forked repo. In fact in the guide on the wiki I've explicitly written that one should always clone a fresh repository to make a release, and I stand by this, because this avoids all kinds of issues:

• forgetting to pull the lastest main before making a release
• accidentally pushing to forked repo instead of origin

Also, in case of python packages published on PYPI, pushing the release branch to origin allows you to publish the release on TestPyPI first, where you can verify the package before the actual release. This is not possible to do from fork due to missing PYPI secrets.

[unkcpz]

pushing the release branch to origin allows you to publish the release on TestPyPI first, where you can verify the package before the actual release.

This is a good point and I totally agree. So we can either always ask to run bumpver from a newly cloned folder or add a option to bumpver to push to a certain remote. Let's discuss in person.