Distros actually need to do this fairly regularly for security patches and packaging tweaks, so it may be a good idea. I think local updates were one of the intended uses for post-releases, but that doesn't work if upstream is also using that suffix (and we know some projects do).
*If* this was added to the PEP, I would add it as a new optional ".localN" suffix, with a recommendation that public index servers MUST disallow use of local numbering, since it is intended for downstream integrators to indicate the inclusion of additional changes relative to the upstream version. Outside a given integrators environment, the local numbering is no longer valid. Currently, the PEP assumes the use of an external numbering system to track that kind of local change (e.g. with RPM, one common tactic is to increase the release level rather than the version, so the version continues to match the upstream base). The rationale for adding it directly to the PEP would be to let people accurately track versions for local modifications, even if they're using virtualenv as their integration environment. "Provides" is a bit different, in that it covers more permanent forks and name changes, rather than the "fix things locally for immediate use, submit upstream patch as a good open source citizen" and "backport selected bug fixes from later versions" workflows that are pretty common in larger integration projects like Linux distros. Cheers, Nick. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
