You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Could pyclipper tag its future releases according to semantic versioning? For example, the last release was tagged as 1.1.0.post3 which isn’t quite according to the spec; see test page. It’s certainly not the end of the world to ignore semver.org, but some Linux distributions actually assume that projects follow semantic versioning. Maybe pyclipper could simply tag its future releases as major.minor.patch?
The text was updated successfully, but these errors were encountered:
Hi Sascha!
I try to follow semver already. Those post-releases you see do not actually change the code of the library so downstream maintainers can ignore them, only CI metadata required to compile the wheel packages changes but that's only used by our own Travis or Appveyor setup. Sometimes I need to increment the version string because PyPI index doesn't accept the same package version uploaded more than once.
The .post suffix are legal according to the python version specification PEP440
Sure, I could alternatively bump the third last digit (bugfix) every time, even when no actual code changes occur, but that would signal that something has changed where it has not, in practice.
Could pyclipper tag its future releases according to semantic versioning? For example, the last release was tagged as 1.1.0.post3 which isn’t quite according to the spec; see test page. It’s certainly not the end of the world to ignore semver.org, but some Linux distributions actually assume that projects follow semantic versioning. Maybe pyclipper could simply tag its future releases as
major.minor.patch
?The text was updated successfully, but these errors were encountered: