Add a section called Final Release Notes to collect information about
why and how a final release is special.
This commit is contained in:
parent
5ab9c0e9d2
commit
c0b5becab4
23
pep-0101.txt
23
pep-0101.txt
|
@ -529,7 +529,28 @@ What Next?
|
|||
be responsible for making commits to the branch. He's going to
|
||||
use this to build the MacOS versions. He may send you information
|
||||
about the Mac release that should be merged into the informational
|
||||
pages on SourceForge or www.python.org.
|
||||
pages on SourceForge or www.python.org. When he's done, he'll
|
||||
tag the branch something like "rX.YaZ-mac". He'll also be
|
||||
responsible for merging any Mac-related changes back into the
|
||||
trunk.
|
||||
|
||||
|
||||
Final Release Notes
|
||||
|
||||
The Final release of any major release, e.g. Python 2.2 final, has
|
||||
special requirements, specifically because it will be one of the
|
||||
longest lived releases (i.e. betas don't last more than a couple
|
||||
of weeks, but final releases can last for years!).
|
||||
|
||||
For this reason we want to have a higher coordination between the
|
||||
three major releases: Windows, Mac, and source. The Windows and
|
||||
source releases benefit from the close proximity of the respective
|
||||
release-bots. But the Mac-bot, Jack Jansen, is 6 hours away. So
|
||||
we add this extra step to the release process for a final
|
||||
release:
|
||||
|
||||
___ Hold up the final release until Jack approves, or until we
|
||||
lose patience <wink>.
|
||||
|
||||
|
||||
Windows Notes
|
||||
|
|
Loading…
Reference in New Issue