Accepting PEP 440: Version Identification and Dependency Specification
I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies when distributing Python software. The PEP is available in the usual place at http://www.python.org/dev/peps/pep-0440/ It's been a long road to get to an implementation independent versioning standard that has a feasible migration path from the current pkg_resources defined de facto standard, and I'd like to thank a few folks: * Donald Stufft for his extensive work on PEP 440 itself, especially the proof of concept integration into pip * Vinay Sajip for his efforts in validating earlier versions of the PEP * Tarek Ziadé for starting us down the road to an implementation independent versioning standard with the initial creation of PEP 386 back in June 2009, more than five years ago! Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Wow, a huge thanks to everyone named (as well as you, Nick ;) for persevering and getting this through. On 22 August 2014 22:34, Nick Coghlan <ncoghlan@gmail.com> wrote:
I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies when distributing Python software.
The PEP is available in the usual place at http://www.python.org/dev/peps/pep-0440/
It's been a long road to get to an implementation independent versioning standard that has a feasible migration path from the current pkg_resources defined de facto standard, and I'd like to thank a few folks:
* Donald Stufft for his extensive work on PEP 440 itself, especially the proof of concept integration into pip * Vinay Sajip for his efforts in validating earlier versions of the PEP * Tarek Ziadé for starting us down the road to an implementation independent versioning standard with the initial creation of PEP 386 back in June 2009, more than five years ago!
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
It is not compatible with http://legacy.python.org/dev/peps/pep-0440/#semantic-versioning Does that mean that packages that choose this way of versioning will not be supported by Python tools anymore? On Fri, Aug 22, 2014 at 4:09 PM, Richard Jones <richard@python.org> wrote:
Wow, a huge thanks to everyone named (as well as you, Nick ;) for persevering and getting this through.
On 22 August 2014 22:34, Nick Coghlan <ncoghlan@gmail.com> wrote:
I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies when distributing Python software.
The PEP is available in the usual place at http://www.python.org/dev/peps/pep-0440/
It's been a long road to get to an implementation independent versioning standard that has a feasible migration path from the current pkg_resources defined de facto standard, and I'd like to thank a few folks:
* Donald Stufft for his extensive work on PEP 440 itself, especially the proof of concept integration into pip * Vinay Sajip for his efforts in validating earlier versions of the PEP * Tarek Ziadé for starting us down the road to an implementation independent versioning standard with the initial creation of PEP 386 back in June 2009, more than five years ago!
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
-- anatoly t.
On Aug 26, 2014, at 5:25 AM, anatoly techtonik <techtonik@gmail.com> wrote:
It is not compatible with http://legacy.python.org/dev/peps/pep-0440/#semantic-versioning Does that mean that packages that choose this way of versioning will not be supported by Python tools anymore?
I’m not sure what this is saying, what part of PEP 440 isn’t compatible with that section you linked? --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
Hi, Nick Coghlan <ncoghlan <at> gmail.com> writes:
I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies when distributing Python software.
It would be nice if such accepted PEPs were also announced on python-dev. Always good to keep people informed :-) cheers (and congrats for the PEP) Antoine.
On Fri, Aug 22, 2014 at 10:34:39PM +1000, Nick Coghlan wrote:
I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies when distributing Python software.
The PEP is available in the usual place at http://www.python.org/dev/peps/pep-0440/
Awesome! Minor nit: http://legacy.python.org/dev/peps/pep-0440/#final-releases still uses the older N[.N]+ spelling, which perhaps should be changed to N(.N)* to be consistent with http://legacy.python.org/dev/peps/pep-0440/#public-version-identifiers and to make it more apparent at a glance that one number with no dots is also a valid version identifier. Marius Gedminas -- NT 5.0 is the last nail in the Unix coffin. Interestingly, Unix isn't in the coffin... It's wondering what the heck is sealing itself into a wooden box 6 feet underground... -- Jason McMullan
On 2 September 2014 16:43, Marius Gedminas <marius@pov.lt> wrote:
Minor nit: http://legacy.python.org/dev/peps/pep-0440/#final-releases still uses the older
N[.N]+
spelling, which perhaps should be changed to
N(.N)*
to be consistent with http://legacy.python.org/dev/peps/pep-0440/#public-version-identifiers and to make it more apparent at a glance that one number with no dots is also a valid version identifier.
Indeed, I missed that reference when we made the change to allow Firefox/Chrome style version numbers. Fixed in http://hg.python.org/peps/rev/ff38b758e584 Thanks for pointing it out! Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hi all, On Fri, Aug 22, 2014 at 22:34 +1000, Nick Coghlan wrote:
I just pushed Donald's final round of edits in response to the feedback on the last PEP 440 thread, and as such I'm happy to announce that I am accepting PEP 440 as the recommended approach to identifying versions and specifying dependencies when distributing Python software.
The PEP is available in the usual place at http://www.python.org/dev/peps/pep-0440/
It's been a long road to get to an implementation independent versioning standard that has a feasible migration path from the current pkg_resources defined de facto standard, and I'd like to thank a few folks:
* Donald Stufft for his extensive work on PEP 440 itself, especially the proof of concept integration into pip * Vinay Sajip for his efforts in validating earlier versions of the PEP * Tarek Ziadé for starting us down the road to an implementation independent versioning standard with the initial creation of PEP 386 back in June 2009, more than five years ago!
Only got to look at PEP440 now and like it. Thanks to all who helped to sort this out! best, holger
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
participants (7)
-
anatoly techtonik -
Antoine Pitrou -
Donald Stufft -
holger krekel -
Marius Gedminas -
Nick Coghlan -
Richard Jones