Changes between Version 94 and Version 95 of TracDev/ReleaseChecklist
- Timestamp:
- Jul 17, 2015, 1:00:27 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TracDev/ReleaseChecklist
v94 v95 5 5 == Version identification 6 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.7 The //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 8 9 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 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 benecessary in the event of a packaging or uploading error.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 is necessary in the event of a packaging or uploading error. 12 12 13 13