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

Use proper semantic version #9

Closed
unmade opened this issue Nov 14, 2018 · 2 comments
Closed

Use proper semantic version #9

unmade opened this issue Nov 14, 2018 · 2 comments

Comments

@unmade
Copy link

unmade commented Nov 14, 2018

Hi,

Can you please also do release tags like 0.6.4 (without dev20181101 part)?

The thing is when I'm trying to install sanic-cors with pipenv it can't resolve SPF dependency.
There is a workaround to specify pipenv install sanic-cors --pre to resolve pre-release dependency, BUT this flag affects all other dependencies (for example it will coverage==5.0.3a, etc).

I saw previous ticket

@ashleysommer
Copy link
Owner

ashleysommer commented Nov 14, 2018

@unmade
Thanks for the issue report.
Sanic Plugins Framework uses PEP-440 Versioning, not Semantic Versioning (semver), because PEP-440 is better suited to native python projects in the python ecosystem.

While I did know that pipenv doesn't install pre-release software by default, I didn't know that pipenv considers .devN suffixes to be pre-releases. Perhaps that is a misinterpretation on my behalf.
Reading this section of PEP-440 in Developmental Releases:
https://www.python.org/dev/peps/pep-0440/#id27
It shows that .devN can be applied on pre-release, release-candidate, release, and post-release versions. Therefore to me a developmental release is not the same as a pre-release.
In fact, see this section in PEP-440 regarding compatibility with other forms of semantic-versioning:
https://www.python.org/dev/peps/pep-0440/#id48
Specifically:

One possible mechanism to translate such semantic versioning based source labels to compatible public versions is to use the .devN suffix

So to me that implies that using .devN will increase compatibility of publicly released versions, with semantic versioing systems, not decrease it.

I'm happy with PEP-440 versioning and see no need to switch to semver. I will open an issue on the pipenv repo about this to try to get it fixed.

Having said all that, I actually think that the SPF has perhaps outgrown the .devN suffix, I was only using that in the early stages of development as a way of tagging releases with release-dates without changing the implied semantics of the version. And I just kept it going on the later versions because that is how the previous versions were done, and the datestamps were still useful to me.

Maybe this is a good opportunity to bump up to 1.0.0 release, perhaps timing it with the Sanic 2018.12 release.

@unmade
Copy link
Author

unmade commented Nov 15, 2018

Thanks for understanding and solving this problem!
It was a hot discussion in pipenv repo. Hopefully they have plans to impletent --pre flag for individual package.

@unmade unmade closed this as completed Nov 15, 2018
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

2 participants