Clarification on the automatic conversion of draft version

Hello Team,

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?

Thanks,
Aravind Venkat

What build system are you using?

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.

We are using Jenkins to build and publish the python library to artifactory

Jenkins is very nice, liked using it.
What matters is the set of jobs you have in your pipelines.
And the code you run for each part of the pipeline.

I meant the tool which creates your package. Is it build, flit, hatch, pdm, poetry, setuptools, something else?

The first place I would look to troubleshoot an issue like this is the package tool’s configuration.

setuptools

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.

We have version string set in setup.py

Is this the problem: package name normalization?

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 :wink:
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?

From PEP 440:

Pre-release spelling

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.