Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'languages.': 0.04; '(even': 0.05; 'widely': 0.05; '(so': 0.07; 'pypi': 0.07; 'subject:support': 0.07; 'parsing': 0.09; 'pep': 0.09; 'semantic': 0.09; 'subject:module': 0.09; 'subject:number': 0.09; 'subject:version': 0.09; 'supported,': 0.09; 'python': 0.11; '(just': 0.16; '(taken': 0.16; '1.0.0': 0.16; '1.0a1': 0.16; '1.0b2': 0.16; 'format:': 0.16; 'gained': 0.16; 'naming': 0.16; 'received:80.67': 0.16; 'received:80.67.31': 0.16; 'received:ispgateway.de': 0.16; 'rough': 0.16; 'skip:[ 30': 0.16; 'skip:n 50': 0.16; 'url:peps': 0.16; 'skip:= 10': 0.16; 'discussion': 0.18; 'module': 0.19; 'commit': 0.19; 'numerical': 0.19; 'version.': 0.19; 'examples': 0.20; 'programming': 0.22; 'comparing': 0.24; 'url:dev': 0.24; 'versions': 0.24; 'cheers,': 0.24; 'handling': 0.26; 'post': 0.26; 'least': 0.26; 'point': 0.28; 'skip:p 30': 0.29; 'patch': 0.29; '[2]': 0.30; 'compared': 0.30; 'specified': 0.30; 'boundary': 0.31; 'follows': 0.31; 'libraries': 0.31; 'schemes': 0.31; 'skip:= 40': 0.31; 'staying': 0.31; 'class': 0.32; 'another': 0.32; 'url:python': 0.33; "i'd": 0.34; 'could': 0.34; 'there': 0.35; 'version': 0.36; 'scheme': 0.36; 'next': 0.36; 'hi,': 0.36; 'url:org': 0.36; 'should': 0.36; 'same.': 0.38; 'to:addr:python-list': 0.38; 'short': 0.38; 'does': 0.39; 'supporting': 0.39; 'to:addr:python.org': 0.39; 'according': 0.40; 'release': 0.40; 'even': 0.60; 'solve': 0.60; 'numbers': 0.61; 'first': 0.61; 'header:Message-Id:1': 0.63; 'personal': 0.63; 'such': 0.63; 'skip:1 20': 0.65; 'within': 0.65; 'world': 0.66; 'between': 0.67; 'increase': 0.74; 'special': 0.74; 'attention': 0.75; '440': 0.84; 'increases': 0.91; 'officially': 0.91; 'differences': 0.93 From: =?iso-8859-1?Q?J=F6rn_Hees?= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: module version number support for semver.org Date: Fri, 11 Apr 2014 00:45:35 +0200 To: python-list@python.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Df-Sender: bWFpbEBqb2VybmhlZXMuZGU= X-Mailman-Approved-At: Fri, 11 Apr 2014 01:01:10 +0200 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 114 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1397170871 news.xs4all.nl 2842 [2001:888:2000:d::a6]:38760 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:70068 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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'.=20 Ideas to solve (cross scheme) comparisons =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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=F6rn