Improve RC workflow: Enhanced validation and error handling in Makefile

[borland667]

What?

• Improved the bump-test-version target in the Makefile to ensure proper validation of the provided release candidate (RC) versions.
• Added logic to fetch the latest version and the latest RC version from PyPI.
• Implemented checks to validate that the provided RC version is either starting from rc0 if no RC versions exist or incrementing the latest RC version from PyPI.
• Enhanced error handling and messaging to provide clearer feedback during the version bump process.

Why?

• To ensure that version increments are consistent and follow the existing versioning scheme on PyPI.
• To prevent invalid RC versions from being set, which could lead to confusion and potential issues during the release process.
• To automate the version bump process with proper validation, reducing manual errors and improving the release workflow.
• To provide clear and informative messages to developers when using the Makefile, improving the overall development experience.

References

• Refer to the Makefile best practices for additional context on the changes made.

Before release

Review the checklist here

[coveralls]

Pull Request Test Coverage Report for Build 9271628389

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 69.031%

---

Totals
Change from base Build 8847843590:	0.0%
Covered Lines:	2018
Relevant Lines:	2812

---

💛 - Coveralls

[angelofenoglio]

Maybe we can document the version calculation logic so that we can all easily review it, makefile syntax makes it a little hard to follow, what do you think?

[angelofenoglio]

At the time of writing this comment:

$ curl -sL "https://pypi.org/pypi/leverage/json" | jq -r '.releases | keys[]' | sort -V | tail -n 2
1.12.3
1.12.3rc1

And so, after running these two statements

LATEST_VERSION=1.12.3rc1
LATEST_RC_VERSION=""

since rcs currently do not use the dash separator. But if we ignore this, both variables would hold the same value.
Suppose we don't have 1.12.3rc1 as a released version, we would end up with something like

LATEST_VERSION=1.12.3
LATEST_RC_VERSION=1.12.2rc3

which would create various different issues down the line like attempting to release 1.12.3rc4 without the previous 3 existing (following the logic in lines 77 to 83).

Couldn't we rely only on LATEST_VERSION?

[angelofenoglio]

By accepting PROVIDED_RC_VERSIONs that are lesser or equal that the current latest rc version we will most likely clash with an already existing release, wouldn't we? also we wouldn't be able to progress in the rcs version if I'm not mistaken.
I think rcs should be always incrementing in version number since they are for testing purposes, what do you think about it?