Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix the python and RPM release and version strings #508

Open
mambelli opened this issue Sep 8, 2021 · 5 comments
Open

Fix the python and RPM release and version strings #508

mambelli opened this issue Sep 8, 2021 · 5 comments
Assignees

Comments

@mambelli
Copy link
Contributor

mambelli commented Sep 8, 2021

We need a tagging and versioning scheme that works well for Git, Python and the RPMs.
Currently I've been tagging the RC and dev releases for x.y.(z+1) as x.y.z.postN, but this is causing problems w/ the automatic versions for the tests: x.y.z.postN.postM+VVVV is not a valid pep440 schema.
Then it is not ideal.
I'd like something that gives me good python versions and good RPM versions (with a tag that Git is not complaining about).
~ would be a separator ignored by Python and useful in RPMs but cannot be used in Git tags.
I think setup tools allow functions to convert the version/release strings.
I need something like (git/python -> RPM): 1.2.3 -> 1.2.3-1 , 1.3.0a2 -> 1.3.0~a.2-1, 1.4.2c4 -> 1.4.3-0.4.rc4-1 (1.4.3~c.4-1 acceptable)

@jcpunk
Copy link
Contributor

jcpunk commented Sep 8, 2021

I've whipped up pypa/setuptools#2778 as a possible way to work around this issue. Currently the %version macro is hard coded to match the version string of the metadata. With this PR merged, I can split out the items from setuptools_scm to get pretty close to what you're after.

@jcpunk
Copy link
Contributor

jcpunk commented Sep 8, 2021

For now, if you tag as X.Y.ZrcQ that should fix up the actions workflow as X.Y.ZrcQ.postN should be a valid version. That doesn't fix up RPM thinking it is a "bigger" package than the official release, but it would get the workflows passing again.

@jcpunk jcpunk self-assigned this Sep 9, 2021
@StevenCTimm
Copy link

Note that in the dev repo 1.7.99.post1 is somehow considered <= 1.7.0.post1 please investigate

@mambelli
Copy link
Contributor Author

mambelli commented Feb 3, 2022

Hi @StevenCTimm, that's strange. For me, it seems to come after. How did it happen to you?

$ rpmdev-vercmp  1.7.99.post1 1.7.0.post1
1.7.99.post1 > 1.7.0.post1
$ yum --enablerepo=ssi-hepcloud-dev list --showduplicates decisionengine\*
...
decisionengine.noarch                                                                1.7.0-1                                                                     ssi-hepcloud-dev
decisionengine.noarch                                                                1.7.0.post1-1                                                               ssi-hepcloud-dev
decisionengine.noarch                                                                1.7.1-1                                                                     ssi-hepcloud
decisionengine.noarch                                                                1.7.99.post1-1                                                              ssi-hepcloud-dev
...

@StevenCTimm
Copy link

StevenCTimm commented Feb 25, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants