We are working on building python library and uploading it to the artifactory. While building the python draft version (eg: version: 1.0.0-alpha) it is automatically getting converted into 1.0.0-a0 which causes confusion for the developers on the draft version for python.
Can you please provide clarification on this?
Also Is there any option to have the same version (eg: 1.0.0-alpha) while building the python library especially on the draft version?
We used a system where dev versions of built artifact went into a /dev folder.
Then when CI or human QA agreed its release quality it was snapshotted into a /release.
It can also have a date time stanza in the url …/dev/2023/09/26/083723/
I would not use the alpha marker at all. Just set the version unique for any production release.
We used to have the build CI set the last part of the version so each build had a unique version.
And where is your version string set? Via __version__ in __init__.py, or in setup.py, or in pyproject.toml, or somewhere else?
The version string changes because one of your tools is configured to change it. To solve your problem, follow the version string through your pipeline and figure out where it’s changed.
If your users find this strange, then I assume they are not that familiar with Python versioning/packaging. You could tell them that it’s good for their dev careers if they familiarize themselves a bit more with this
Or if they ask for install instructions, you could only refer to the package as version “1.0.0-a0”. Or… if you want to cater to them, you could perhaps also consider just not using those “alpha” tags, and use a simple version number?
Pre-releases allow the additional spellings of alpha, beta, c, pre, and preview for a, b, rc, rc, and rcrespectively. This allows versions such as 1.1alpha1, 1.1beta2, or 1.1c3 which normalize to 1.1a1, 1.1b2, and 1.1rc3. In every case the additional spelling should be considered equivalent to their normal forms.