search

ashleysommer / sanic-plugin-toolkit

Easily create Plugins for Sanic!
MIT License
51 stars 9 forks source link

Use proper semantic version #9

Closed unmade closed 5 years ago

unmade commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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.