[Python-checkins] python/nondist/peps pep-0101.txt,1.28,1.29
bwarsaw@users.sourceforge.net
bwarsaw@users.sourceforge.net
Thu, 24 Jul 2003 19:34:05 -0700
Update of /cvsroot/python/python/nondist/peps
In directory sc8-pr-cvs1:/tmp/cvs-serv22940
Modified Files:
pep-0101.txt
Log Message:
updates
Index: pep-0101.txt
===================================================================
RCS file: /cvsroot/python/python/nondist/peps/pep-0101.txt,v
retrieving revision 1.28
retrieving revision 1.29
diff -C2 -d -r1.28 -r1.29
*** pep-0101.txt 21 Jul 2003 17:34:07 -0000 1.28
--- pep-0101.txt 25 Jul 2003 02:34:02 -0000 1.29
***************
*** 45,82 ****
say X.Y.MaZ.
! ___ At noon the day before the release, create a branch for X.YaZ.
! All Python development happens on the trunk. Making releases
! from a branch allows development by the community to continue
! without impacting what ends up in the release. There's a
! natural tension here though: branching too soon causes headaches
! when the branch has to be merged back into the trunk, while
! branching too late can cause dependency problems with
! documentation and Windows release steps.
! The compromise is to create the branch at noon, local time, the
! day before the release. This should give enough time to Fred to
! make the documentation, then for Tim to create the Windows
! installer, both of which need to happen before the release can
! be announced. It's also short enough that hopefully not too
! many trunk changes will need to be merged into the branch, or
! vice versa.
! Once the branch is made, only the RM or his appointed bots are
! allowed to make commits to the branch. You can assume that Fred
! is a bot for the Doc/ tree, Tim is a bot for the Windows stuff,
! and Jack is a bot for Mac stuff.
! Anyone can continue to make checkins on the trunk, but if such a
! change should be merged into the branch, the committer must
! indicate this in the checkin message. It is the responsibility
! of the RM to decide on a case-by-case basis which trunk
! modifications should be merged into the branch.
! To create a branch the following steps are taken:
___ Do a CVS update with the -A, -d, and -P flags, e.g.
% cvs -q update -d -P -A
___ CVS tag the trunk with the symbolic name "rXYaZ-fork", e.g.
% cvs tag r22a3-fork
--- 45,116 ----
say X.Y.MaZ.
! Note: This document has been updated to reflect the more
! streamlined procedures used to release Python 2.3 (including the
! alphas and betas).
! ___ Impose a check-in freeze. Send a message to
! python-dev@python.org telling people not to make any check-ins
! on the tree until further notice.
! At this point, nobody except the RM should make any commits to
! the branch (or his duly assigned agents, i.e. Guido the BDFL,
! Fred Drake for documentation, or Tim Peters for Windows). If
! the RM screwed up and some desperate last minute change to the
! branch is necessary, it can mean extra work for Fred and Tim.
! So try to avoid this!
! ___ Log into irc.freenode.net and join the #python-dev channel.
! You probably need to coordinate with other people around the
! world. This IRC channel is where we've arranged to meet.
! ___ The most important thing to do is to update the Misc/NEWS file.
! Tim will need this in order to do the Windows release and he
! likes to stay up late. This step can be pretty tedious, so it's
! best to get to it immediately after making the branch, or even
! before you've made the branch.
!
! Add high level items new to this release. E.g. if we're
! releasing 2.2a3, there must be a section at the top of the file
! explaining "What's new in Python 2.2a3". It will be followed by
! a section entitled "What's new in Python 2.2a2".
!
! Note that you /hope/ that as developers add new features to the
! trunk, they've updated the NEWS file accordingly. You can't be
! positive, so double check. If you're a Unix weenie, it helps to
! verify with Tim Peters about changes on Windows, and Jack Jansen
! about changes on the Mac.
!
! This command should help you:
!
! % cvs log | python Tools/scripts/logmerge.py > /tmp/news.txt
!
! IOW, you're printing out all the cvs log entries from the
! previous release until now. You can then troll through the
! news.txt file looking for interesting things to add to NEWS.
!
! ___ Tag and/or branch the tree for release X.YaZ
!
! If you're releasing an alpha/beta/release candidate, you will
! just tag the tree. If you are releasing a final release, you
! will tag and create a branch.
!
! All Python development happens on the trunk. While it's
! sometimes challenging to keep people from checking things in
! while you're making a release, it's still preferred to creating
! a short-lived release branch.
!
! Practically speaking, we tag and branch just before making the
! release. Tagging too early causes too much merging work.
___ Do a CVS update with the -A, -d, and -P flags, e.g.
% cvs -q update -d -P -A
+ To tag the tree, do the following:
+
+ ___ cvs tag rXYaZ
+
+ To create a branch the following steps are taken:
+
___ CVS tag the trunk with the symbolic name "rXYaZ-fork", e.g.
% cvs tag r22a3-fork
***************
*** 88,115 ****
You'll be doing a lot of work in this directory and you want
to keep it straight from your trunk working directory. E.g.
- % cvs -d <cvsroot> -q co -d python-22a3 -r r22a3-branch python/dist/src
! ___ Send an email to python-dev@python.org indicating the fork and
! branch tags you've just created.
! ___ Put a freeze on check ins into the branch. At this point,
! nobody except the RM should make any commits to the branch (or
! his duly assigned agents, i.e. Guido the BDFL, Fred Drake for
! documentation, or Tim Peters for Windows). If the RM screwed up
! and some desperate last minute change to the branch is
! necessary, it can mean extra work for Fred and Tim. So try to
! avoid this!
! ___ In the branch, change Include/patchlevel.h in two places, to
reflect the new version number you've just created. You'll want
to change the PY_VERSION macro, and one or several of the
version subpart macros just above PY_VERSION, as appropriate.
! ___ If you're changing the version number for Python (e.g. from
! Python 2.1.1 to Python 2.1.2), you also need to update the
! README file, which has a big banner at the top proclaiming its
! identity. Don't do this if you're just releasing a new alpha or
! beta release, but /do/ do this if you're release a new micro
! release.
___ There's also a mention of the version in
--- 122,138 ----
You'll be doing a lot of work in this directory and you want
to keep it straight from your trunk working directory. E.g.
! % export CVSROOT=cvs.sf.net:/cvsroot/python
! % cvs -q co -d python-22a3 -r r22a3-branch python/dist/src
! ___ cd into the branch directory.
! ___ Change Include/patchlevel.h in two places, to
reflect the new version number you've just created. You'll want
to change the PY_VERSION macro, and one or several of the
version subpart macros just above PY_VERSION, as appropriate.
! ___ Update the README file, which has a big banner at the top
! proclaiming its identity.
___ There's also a mention of the version in
***************
*** 149,221 ****
Doc/whatsnew/whatsnewXX.tex to include the actual release date;
e.g. "Python 2.3 was released on August 1, 2003."
! There's no need to edit this for alpha or beta releases.
!
! ___ For the next few hours, selectively merge stuff from trunk into
! branch. For each change you see on the trunk (i.e. via the
! python-checkins mailing list), you need to decide whether the
! change should also be applied to the branch.
!
! There is a tension here. Announcing the branch often jogs
! people's natural tendency to procrastinate so some very useful
! patches end up getting checked in at the last moment. But the
! Windows and Docs releases tend to be built many hours before the
! source release, and changes to the branch can force a lot of
! wasted effort to rebuild them. The best advice is to be
! judicious and to consult Fred and Tim before adding anything
! big. You really want to avoid skew between the various platform
! releases.
!
! Note that committers of changes to the trunk SHOULD include in
! the checkin message, a note indicating the suitability of their
! patch for the branch.
!
! If so, it's fairly easy to apply the change by diff'ing the file
! and patching it manually. You can also sometimes get away with
! just copying the file from the trunk directory to the branch
! directory, but be careful so you don't lose changes that only
! exist in the branch!
!
! ___ After creating the branch, the most important thing to do next
! is to update the Misc/NEWS file. Tim will need this in order to
! do the Windows release and he likes to stay up late. This step
! can be pretty tedious, so it's best to get to it immediately
! after making the branch, or even before you've made the branch.
! The sooner the better (but again, watch for new checkins up
! until the release is made!)
!
! Add high level items new to this release. E.g. if we're
! releasing 2.2a3, there must be a section at the top of the file
! explaining "What's new in Python 2.2a3". It will be followed by
! a section entitled "What's new in Python 2.2a2".
!
! Note that you /hope/ that as developers add new features to the
! trunk, they've updated the NEWS file accordingly. You can't be
! positive, so double check. If you're a Unix weenie, it helps to
! verify with Tim Peters about changes on Windows, and Jack Jansen
! about changes on the Mac.
!
! This command should help you:
!
! % cvs log -rr22a1: | python Tools/scripts/logmerge.py > /tmp/news.txt
!
! IOW, you're printing out all the cvs log entries from the
! previous release until now. You can then troll through the
! news.txt file looking for interesting things to add to NEWS.
! ___ Check your NEWS changes into the branch and into the trunk.
! ___ Once the branch is frozen, Fred Drake needs to create the HTML
! from the documentation. He does this and uploads the file to
! www.python.org. Then he tells Tim Peters where this file is.
! This may generate some last minute changes on the branch. Once
! Fred is done, there can be no further checkins on the branch in
! the Doc/ directory -- not even by the RM. For final releases,
! Fred also sends email to Milan Zamazal for conversion to the GNU
! Info format, and to Hernan M. Foffani for conversion to HTML
! Help.
- Note that Fred is responsible both for merging doc changes from
- the trunk to the branch AND for merging any branch changes from
- the branch to the trunk during the cleaning up phase.
Basically, if it's in Doc/, Fred will take care of it.
--- 172,190 ----
Doc/whatsnew/whatsnewXX.tex to include the actual release date;
e.g. "Python 2.3 was released on August 1, 2003."
! There's no need to edit this for alpha or beta releases. Note
! that Andrew often takes care of this.
! ___ By now, Fred has created the HTML for the documentation and
! pushed the appropriate files out to www.python.org. Tim needs
! this to build the Windows installer, but the RM doesn't need
! this stuff to build the source distribution.
! Fred tells Tim Peters where the documentation file is. This may
! generate some last minute changes on the branch. Once Fred is
! done, there can be no further checkins on the branch in the Doc/
! directory -- not even by the RM. For final releases, Fred also
! sends email to Milan Zamazal for conversion to the GNU Info
! format, and to Hernan M. Foffani for conversion to HTML Help.
Basically, if it's in Doc/, Fred will take care of it.
***************
*** 224,231 ****
___ Tim performs his Windows magic, generating an installer
! executable. He uploads this file to python.org, and then sends
the RM a notice which includes the location and MD5 checksum of
the Windows executable.
Note that Tim's creation of the Windows executable may generate
a few more commits on the branch. Tim will be responsible for
--- 193,203 ----
___ Tim performs his Windows magic, generating an installer
! executable. He uploads this file to SourceForge, and then sends
the RM a notice which includes the location and MD5 checksum of
the Windows executable.
+ Note that Tim used to upload the installer to www.python.org,
+ but has had problems with ssh for a while now.
+
Note that Tim's creation of the Windows executable may generate
a few more commits on the branch. Tim will be responsible for
***************
*** 233,243 ****
branch to trunk.
! ___ It's Noon!
! Now, you're ready to build the source tarball. First cd to your
! working directory for the branch. E.g.
% cd .../python-22a3
! ___ Do a "cvs update" in this directory. Do NOT include the -A flag!
You should not see any "M" files, but you may see several "P"
--- 205,219 ----
branch to trunk.
! ___ Download the Windows executable from SourceForge to
! creosote.python.org. Tell Tim so he can remove the file from
! SourceForge.
! ___ Time to build the source tarball. If you created a branch, be
! sure to cd to your working directory for the branch. E.g.
% cd .../python-22a3
! ___ Do a "cvs update" in this directory. Do NOT include the -A flag
! if you're working on a branch, but do include it if you're
! working on the trunk.
You should not see any "M" files, but you may see several "P"
***************
*** 246,252 ****
last minute changes.
! ___ Now tag the branch using a symbolic name like "rXYaZ",
! e.g. r22a3
! % cvs tag r22a3
___ Change to a neutral directory, i.e. one in which you can do a
--- 222,228 ----
last minute changes.
! ___ If you've seen updates to existing files, update the cvs tag:
!
! % cvs tag -F r22a3
___ Change to a neutral directory, i.e. one in which you can do a
***************
*** 256,260 ****
% cd ~
! % cvs -d <cvsroot> export -rr22a3 -d Python-2.2a3 python/dist/src
___ Generate the tarball. Note that we're not using the `z' option
--- 232,237 ----
% cd ~
! % export CVSROOT=cvs.sf.net:/cvsroot/python
! % cvs export -rr23c2 -d Python-2.3c2 python/dist/src
___ Generate the tarball. Note that we're not using the `z' option
***************
*** 262,269 ****
as far as we know, and 2) we're going to max out the compression
level, which isn't a supported option.
! % tar cf - Python-2.2a2 | gzip -9 > Python-2.2a2.tgz
___ Calculate the MD5 checksum of the tgz file you just created
! % md5sum Python-2.2a2.tgz
Note that if you don't have the md5sum program, there is a
--- 239,248 ----
as far as we know, and 2) we're going to max out the compression
level, which isn't a supported option.
!
! % tar cf - Python-2.3c2 | gzip -9 > Python-2.3c2.tgz
___ Calculate the MD5 checksum of the tgz file you just created
!
! % md5sum Python-2.3c2.tgz
Note that if you don't have the md5sum program, there is a
***************
*** 276,281 ****
% cd /tmp
! % tar zxvf ~/Python-2.2a3.tgz
! % cd Python-2.2a3
% ls
(Do things look reasonable?)
--- 255,260 ----
% cd /tmp
! % tar zxvf ~/Python-2.3c2.tgz
! % cd Python-2.3c2
% ls
(Do things look reasonable?)