Re: [Distutils] version for VCS/local builds between alpha and release
On 15 April 2015 at 19:33, Robert Collins 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-versioning.rst Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] version for VCS/local builds between alpha and release
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 wrote: > > On 14 Apr 2015 04:04, "Robert Collins" 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 Distinguished Technologist HP Converged Cloud ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] version for VCS/local builds between alpha and release
On 14 Apr 2015 04:04, "Robert Collins" 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. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] version for VCS/local builds between alpha and release
On 14 April 2015 at 23:31, Joost Molenaar wrote: > On 14 April 2015 at 10:04, Robert Collins 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 Distinguished Technologist HP Converged Cloud ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] version for VCS/local builds between alpha and release
On 14 April 2015 at 10:04, Robert Collins 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] 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 Distinguished Technologist HP Converged Cloud ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
