Bump package version for post release

[mtreinish]

Summary

The 0.25.2 release had a number of packaging issues relating to CI and versioning. This commit bumps the terra package version to 0.25.2.post0 which is a post-release notation that is pep440 compliant. The actual version.txt file is not updated in this PR because we still want it to show as 0.25.2 for qiskit.__version__, this is just a re-packaging of the 0.25.2 release.

Details and comments

[qiskit-bot]

One or more of the the following people are requested to review this:

• @Qiskit/terra-core

[wshanks]

Is is necessary to depend on the post specifier? PEP440 says:

Some projects use post-releases to address minor errors in a final release that do not affect the distributed software (for example, correcting an error in the release notes).

and

The use of post-releases to publish maintenance releases containing actual bug fixes is strongly discouraged. In general, it is better to use a longer release number and increment the final component for each maintenance release.

So I would think that if there is something in the post release that affects the software behavior, it would be better to make a 0.25.2.1 while if it does not affect behavior it would be better to release post0 while still leaving the dependency as 0.25.2.

[mtreinish]

Well it's kind of arguable whether this is a bug in the deployed software or not. The fundamental issue is the license file is missing from the 0.25.2 sdist which I think is borderline as to whether it affects the distributed software (I could see it either way). But, the precompiled wheels all should be complete and intact (qiskit 0.44.2 is missing but we could manually publish that if needed). That being said I hadn't considered using 0.25.2.1 that works for me. I think we'd still need to adjust the metapackage to pin to that exactly though, because 0.25.2 is implicitly 0.25.2.0 per PEP440 so it wouldn't match, but the notation works for me if that's easier to work with.

[wshanks]

For the conda-forge package, 0.25.2.1 is easier because I can just skip 0.25.2 and let the automation generate 0.25.2.1.

I can make the post method work as well. It would just require making some temporary workarounds in the conda recipes, making the release, and then removing the temporary workarounds.

[mtreinish]

That's a good enough reason for me, I'll update this to use 0.25.2.1 instead of 0.25.2.post0

[jakelishman]

There's a least one place in Qiskit where we assume that the version is a three-part object (QPY), and there may be others, but I don't think it'll really matter, because I think we would just silently discard a fourth component.

Do any of our CI automation parsing components (qiskit-bot, git-tag inspection, etc) assume a three-part version string, or use some parsing that's based on assuming it's three integers separated by dots?

[mtreinish]

qiskit-bot does the tag handling via the packaging library so it should be good on that front and only deals with the first 3 numbers. All the other places I can think of do similar matching. We went through a similar exercise with the first pre-release. I feel like 0.25.2.post0 might be a bit less likely to cause any issues, but I don't think either version string will have an issue.

[jakelishman]

That's what I thought too, just wanted a second opinion.