version for VCS/local builds between alpha and release
Tl;dr: I woud like to change PEP-440 to remove the stigmata around dev versions that come between pre-releases and releases. The basic scenario here is developers and CD deployers building versions from VCS of arbitrary commits. So we need to be able to deliver strictly increasing version numbers, automatically, without interfering with actual publishing of pre-release and release versions to PyPI. Today, this is fairly sane as a sort order and mechanism to deliver this:
v = ['1.0', '1.2.3.a1.dev1', '1.2.3.a1', '1.2.3.a2.dev1', '1.2.3.b1', '1.2.3.b2.dev1', '1.2.3.rc1', '1.2.3.rc2.dev1', '1.2.3', '1.2.3.dev1'] sorted(v, key=packaging.version.parse) ['1.0', '1.2.3.dev1', '1.2.3.a1.dev1', '1.2.3.a1', '1.2.3.a2.dev1', '1.2.3.b1', '1.2.3.b2.dev1', '1.2.3.rc1', '1.2.3.rc2.dev1', '1.2.3']
But it doesn't feel good using a 'strongly recommended against' order. I think the recommendation is overly strong: If we touch up the language we can make the spec clearer, and a simple example like above will speak a thousand words :). -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
On 14 April 2015 at 10:04, Robert Collins <robertc@robertcollins.net> wrote:
The basic scenario here is developers and CD deployers building versions from VCS of arbitrary commits. So we need to be able to deliver strictly increasing version numbers, automatically, without interfering with actual publishing of pre-release and release versions to PyPI.
I think the advice in PEP440 about using dev tags[1] is a little misguided, because dev tags count towards a known version in the future, while DVCS tags (at least in Git) count the number of commits since a known version in the past. In this respect, 'git describe' most closely resembles the post release tags in PEP440, so that's what I've chosen to use in my build scripts, in spite of the recommendations in PEP440. [1] https://www.python.org/dev/peps/pep-0440/#dvcs-based-version-labels -- Joost Molenaar
On 14 April 2015 at 23:31, Joost Molenaar <j.j.molenaar@gmail.com> wrote:
On 14 April 2015 at 10:04, Robert Collins <robertc@robertcollins.net> wrote:
The basic scenario here is developers and CD deployers building versions from VCS of arbitrary commits. So we need to be able to deliver strictly increasing version numbers, automatically, without interfering with actual publishing of pre-release and release versions to PyPI.
I think the advice in PEP440 about using dev tags[1] is a little misguided, because dev tags count towards a known version in the future, while DVCS tags (at least in Git) count the number of commits since a known version in the past. In this respect, 'git describe' most closely resembles the post release tags in PEP440, so that's what I've chosen to use in my build scripts, in spite of the recommendations in PEP440.
[1] https://www.python.org/dev/peps/pep-0440/#dvcs-based-version-labels
Fair enough - what we're doing is using semver to predict the next version based on the git history - for instance the pseudo header Sem-Ver: api-break will cause the next version to be a major version up. -Rob -- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
On 14 Apr 2015 04:04, "Robert Collins" <robertc@robertcollins.net> wrote:
Tl;dr: I woud like to change PEP-440 to remove the stigmata around dev versions that come between pre-releases and releases.
The basic scenario here is developers and CD deployers building versions from VCS of arbitrary commits. So we need to be able to deliver strictly increasing version numbers, automatically, without interfering with actual publishing of pre-release and release versions to PyPI.
We'd had a previous request for a similar clarification around local version identifiers, so I've finally tweaked the PEP to clarify that both that admonition and this one relate specifically to *published* versions, rather than what folks do with their local or CI builds. See https://hg.python.org/peps/rev/bf4ffb364faf for the exact wording change. Cheers, Nick.
Thanks. There's still a little too much negative there for me - if I propose a diff here would that be ok? On 16 April 2015 at 11:26, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 14 Apr 2015 04:04, "Robert Collins" <robertc@robertcollins.net> wrote:
Tl;dr: I woud like to change PEP-440 to remove the stigmata around dev versions that come between pre-releases and releases.
The basic scenario here is developers and CD deployers building versions from VCS of arbitrary commits. So we need to be able to deliver strictly increasing version numbers, automatically, without interfering with actual publishing of pre-release and release versions to PyPI.
We'd had a previous request for a similar clarification around local version identifiers, so I've finally tweaked the PEP to clarify that both that admonition and this one relate specifically to *published* versions, rather than what folks do with their local or CI builds.
See https://hg.python.org/peps/rev/bf4ffb364faf for the exact wording change.
Cheers, Nick.
-- Robert Collins <rbtcollins@hp.com> Distinguished Technologist HP Converged Cloud
On 15 April 2015 at 19:33, Robert Collins <robertc@robertcollins.net> wrote:
Thanks. There's still a little too much negative there for me - if I propose a diff here would that be ok?
Sure, or a PR against the GitHub mirror: https://github.com/pypa/interoperability-peps/blob/master/pep-0440-versionin... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (3)
-
Joost Molenaar -
Nick Coghlan -
Robert Collins