-
Notifications
You must be signed in to change notification settings - Fork 650
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
Feature request : Generating PEP440 compliant versions #2065
Comments
I see no problem adding support for PEP440, but before we write any new code in GitVersion, it would be good if you could try the various configuration options GitVersion provides to see whether it gives you the desired result. If you add |
Hello @asbjornu , Thanks for the tip! I've just tried playing around with the possible GitVersion.yml configurations; and the following branch description seem to fit the parsing regex from PEP440. branches:
master: {}
release:
tag: 'rc'
feature:
tag: 'dev'
develop:
tag: 'a'
hotfix:
tag: 'post' Such configurations are generating versions which look like : I still think it would be quite nice to integrate this standard directly into GitVersion, as it would be nice to generate a version number following the Public Version Identifier format directly, and also to avoid setting those configs in every single python project. What do you think? |
Thanks for figuring out the required config to get this to work. It's very helpful to see for someone not intimately familiar with PEP440 such as myself. If we were to introduce a variable that changed the default pre-release tags for all branches to be PEP440 compliant, how would you suggest that will look like? |
Well, that is exactly the problem I encountered that pushed me to open an issue here. |
Yes. I don't want to change the GitVersion defaults to be PEP440 compatible, since its's PEP440 that is the odd one out here not supporting SemVer 2.0. But we can add a configuration option to |
Yeah, neither do I; the gitversion standards/defaults are sane. Adding some kind a switch to tell gitversion we want to print out PEP440 compliant versions sound like a good idea. Maybe we could add something like the following option to the GitVersion.yml file :
(or And then, if that switch is enabled, gitversion could print out something of the sort :
Where the X:Y matching could look like this :
I am not aware of other version schemes (but woundn't be surprised if I stumble across one tomorrow); SemVer is pretty much established as a strong standard, the python community just likes to reinvent things. What do you think? |
I think the word I like the word |
@asbjornu just add the milestone 6.0.0 so that we can track it |
I just realized that the de facto standard package manager for PHP, Composer, implements a subset of SemVer in its requirement of prerelease labels of
Otherwise, I believe Composer's implementation is SemVer 2.0 compliant. It's therefore not unthinkable that |
Docker is another one with peculiar format requirements for its tags. I've discovered that |
that's quite true. docker tags are not full semVer compitble. However, imho this only affects the build metada (indicated by +). this ticket seems to be about PEP440 compliancy, or in a broader scope, the generation of the PreRelease* Properties. Maybe it's wise to keep the metadata issue on docker tags out of here for now... @asbjornu thx for guiding me here (coming from #2353), solving PEP440 problems seems to be quite similar to my problem. @franknarf8 could you pls add two example on what PreRelease* and SemVer* Properties you would like to see, so I can check wether we are really in the same boat? In general I'd always think some formatting-string with attached variables (like I can use {branchName} on branches.XX.tag="dev-{BranchName}" has great flexibility, if {PreReleaseNumber} was available (and baked in by default), anyone trying to get rid of it could just get that done. Do I understand correctly that {PreReleaseNumber} is just the commit-count since the last release? Effectivly this is the commit-count since the last tag? |
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions. |
Hello,
We are using GitVersion to version packages written in many different languages and up to now; most package managers are supporting classic SemVer.
We now want to use GitVersion to version for our Python packages; thing is, the Python community decided to invent their own version standard which is not compatible with SemVer : PEP440.
e.g. a pre-release tag can only be equal to a predefined list (So something like
0.6.3-featurebranch.10
is forbidden) (See https://www.python.org/dev/peps/pep-0440/#appendix-b-parsing-version-strings-with-regular-expressions)I know GitVersion is mainly .Net oriented, but would it be possible to also print out PEP440 compliant version numbers along with the other versions numbers? And while leveraging the various development mode GitVersion offers?
Thanks again, we love your tool!
- Frank
The text was updated successfully, but these errors were encountered: