Choosing a versioning scheme for packaging gabbar on PyPI

bkowshik commented 7 years ago

Per https://packaging.python.org/distributing/#choosing-a-versioning-scheme

Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible public version scheme specified in PEP 440 in order to be supported in tools and libraries like pip and setuptools.

PEP 440

Here are some examples of compliant version numbers:

1.2.0.dev1  # Development release
1.2.0a1     # Alpha Release
1.2.0b1     # Beta Release
1.2.0rc1    # Release Candidate
1.2.0       # Final Release
1.2.0.post1 # Post Release
15.10       # Date based release
23          # Serial release

cc: @rodowi @sgillies

bkowshik commented 7 years ago

Let's try to stick to Semantic Versioning 2.0.0 whenever possible. 😄

From http://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

    MAJOR version when you make incompatible API changes,
    MINOR version when you add functionality in a backwards-compatible manner, and
    PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

defvol commented 7 years ago

👍 for semver

mapbox / gabbar

Choosing a versioning scheme for packaging gabbar on PyPI #7