| | 4 | |
| | 5 | == Version identification |
| | 6 | |
| | 7 | A //major.minor.micro// semantic versioning scheme is followed, with guidance from PEP:0440. However, since the //major// version is rarely incremented, we generally refer to a 1.x release a //major// release and a 1.x.y release a //minor// release. |
| | 8 | |
| | 9 | In the event that a critical defect is discovered after a release is made, the //micro// version number should be incremented and a new //minor// release created. In the event that a packaging or distribution error results in the need to generate a new package name, a [PEP:0440#post-releases post-release] identifier should be added, starting with `post1`. The post-release identifier is added by editing `tag_build` in [browser:/trunk/setup.cfg setup.cfg]. |
| | 10 | |
| | 11 | For example, a filename cannot be reused when uploading to PyPI [https://mail.python.org/pipermail/distutils-sig/2015-January/025683.html more than once], so a post-release would be necessary in the event of a packaging or uploading error. |
| | 12 | |
