J
Jörn Hees
Hi,
what do you think about officially supporting Semantic Versioning?
( http://semver.org )
Semantic Versioning has gained a lot of attention in other programming
languages. Even though not officially supported, many python libraries use it
as well (just search the pypi listing for things like "-alpha" "-beta" "-dev"
"-pre" to get a rough idea). There even is a class handling Semantic Versioning
in pip already: pip.util.version.SemanticVersion .
I'd speak in favor of officially adding support for semantic versioning to the
python module versioning specs as a follow up to PEP 440
( http://legacy.python.org/dev/peps/pep-0440/ ).
I want to avoid the fruitless discussion about personal versioning scheme
preference.
My main point is: both schemes are widely used (even in the python world).
As far as i can see both schemes can just co-exist in the python world giving
us the benefits of both without hurting us.
Short re-cap of both versioning schemes
=======================================
The current version format specified in PEP 440 [2] follows this pseudo format:
[N:]N(.N)*[{a|b|c|rc}N][.postN][.devN]
So python module version numbers look like (taken from [2]):
1.0.dev456
1.0a1
1.0a2.dev456
1.0a12.dev456
1.0a12
1.0b1.dev456
1.0b2
1.0b2.post345.dev456
1.0b2.post345
1.0c1.dev456
1.0c1
1.0
1.0.post456.dev34
1.0.post456
1.1.dev1
Semantic Versioning follows this pseudo format:
N.N.N(-((N)|([0-9A-Za-z-]+))(.((N)|([0-9A-Za-z-])+))*)?
Some examples in order (taken from http://semver.org ):
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta
1.0.0-beta.2
1.0.0-beta.11
1.0.0-rc.1
1.0.0
Key differences
===============
Semantic Versioning supports
- free-text pre-releases without version number such as '-alpha', '-pre' and
the very widely used '-dev' (after a release the next commit increases the
version number and appends the '-dev', which is only removed for the release).
- always has MAJOR.MINOR.PATCH, (so 3 relevant) numbers as version number and
offers guidelines which to change when.
Semantic Versioning does not support
- post-releases (a post release would be an increase of the PATCH number).
- special handling for '-dev', '-alpha', '-beta', '-gamma' or 'rc'.
Ideas to solve (cross scheme) comparisons
=========================================
A version comparator could first try parsing both versions to be compared
according to the current scheme and if that fails try parsing them both as
SemanticVersions.
Switching from one version naming scheme to another should be discouraged at
least within the leading N parts at the change boundary staying the same. That
way comparisons between the naming schemes could be settled by comparing the
leading numerical parts of the version.
Cheers,
Jörn
what do you think about officially supporting Semantic Versioning?
( http://semver.org )
Semantic Versioning has gained a lot of attention in other programming
languages. Even though not officially supported, many python libraries use it
as well (just search the pypi listing for things like "-alpha" "-beta" "-dev"
"-pre" to get a rough idea). There even is a class handling Semantic Versioning
in pip already: pip.util.version.SemanticVersion .
I'd speak in favor of officially adding support for semantic versioning to the
python module versioning specs as a follow up to PEP 440
( http://legacy.python.org/dev/peps/pep-0440/ ).
I want to avoid the fruitless discussion about personal versioning scheme
preference.
My main point is: both schemes are widely used (even in the python world).
As far as i can see both schemes can just co-exist in the python world giving
us the benefits of both without hurting us.
Short re-cap of both versioning schemes
=======================================
The current version format specified in PEP 440 [2] follows this pseudo format:
[N:]N(.N)*[{a|b|c|rc}N][.postN][.devN]
So python module version numbers look like (taken from [2]):
1.0.dev456
1.0a1
1.0a2.dev456
1.0a12.dev456
1.0a12
1.0b1.dev456
1.0b2
1.0b2.post345.dev456
1.0b2.post345
1.0c1.dev456
1.0c1
1.0
1.0.post456.dev34
1.0.post456
1.1.dev1
Semantic Versioning follows this pseudo format:
N.N.N(-((N)|([0-9A-Za-z-]+))(.((N)|([0-9A-Za-z-])+))*)?
Some examples in order (taken from http://semver.org ):
1.0.0-alpha
1.0.0-alpha.1
1.0.0-alpha.beta
1.0.0-beta
1.0.0-beta.2
1.0.0-beta.11
1.0.0-rc.1
1.0.0
Key differences
===============
Semantic Versioning supports
- free-text pre-releases without version number such as '-alpha', '-pre' and
the very widely used '-dev' (after a release the next commit increases the
version number and appends the '-dev', which is only removed for the release).
- always has MAJOR.MINOR.PATCH, (so 3 relevant) numbers as version number and
offers guidelines which to change when.
Semantic Versioning does not support
- post-releases (a post release would be an increase of the PATCH number).
- special handling for '-dev', '-alpha', '-beta', '-gamma' or 'rc'.
Ideas to solve (cross scheme) comparisons
=========================================
A version comparator could first try parsing both versions to be compared
according to the current scheme and if that fails try parsing them both as
SemanticVersions.
Switching from one version naming scheme to another should be discouraged at
least within the leading N parts at the change boundary staying the same. That
way comparisons between the naming schemes could be settled by comparing the
leading numerical parts of the version.
Cheers,
Jörn