Switch to 2.4a0 on trunk?

I notice that parts of the trunk are reporting themselves as Python 2.4, but other key parts for Windows are still Python 2.3 - eg, the DLL name, the PC\*.rc files, etc. Should I check code in to move everything to a 2.4 world on the trunk? And while I am asking, I am a little uncertain about the CVS tags. Can someone explain the distinction between release23-branch and release23-fork for me? Is there a branch that will track the "latest 2.3" for the next few years (ie, through 2.3.1, 2.3.2 etc?) Thanks, Mark.

[Mark Hammond]
Please do. I had hoped to do that, but a work crisis has me on the road and I won't be doing anything with Python this week.
Probably, but it doesn't matter <wink>. xyz-fork is just a tag on the HEAD, and xyz-branch is a branch that started life with the stuff with the xyz-fork tag.
Is there a branch that will track the "latest 2.3" for the next few years (ie, through 2.3.1, 2.3.2 etc?)
It doesn't appear that there is yet. Barry? It will be named release23-maint.

On Wed, 2003-07-30 at 21:35, Tim Peters wrote:
Well, here's the problem. The branch was already created with release23-branch, and there doesn't appear to be a way to rename a branch tag. Fred's going to dig into the docs to see if he can find a clue, but if anybody else has direct experience with renaming branch tags, please speak up! I've updated the pep so this won't happen again three years from now when Orlijn releases Python 2.4 <wink>. The other option is to just stick with release23-branch as the maintenance branch tag. -Barry

Barry Warsaw writes:
Boy have we dug! Did the nasty with a test repository as well.
The other option is to just stick with release23-branch as the maintenance branch tag.
Thomas Heller writes:
If these weren't branch tags, that would be exactly what we want. The CVS manual says this doesn't work for branch tags. It's right. Here's what we've come up with: 1. Create a fresh checkout from the release23-branch tag. Capture the cvs output (all the "U somefile" lines) for use in the next step. 2. Massage the cvs output to create input for xargs --null: sed 's/^U //' cvsoutput | tr '\n' '\000' >xargsinput 3. Use xargs --null to drive a cvs admin command: cat xargsinput | xargs --null cvs admin -N release23-maint:release23-branch 4. Send an email to python-dev to let people test. Note that the release23-branch tag is left alone. It's not worth the risk of removing it. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Barry Warsaw <barry@python.org> writes:
Although renaming ordinary tags is straightforward, (update to the old tag, tag with the new name, update to the new name, delete the old tag), this is not the case with branch tags. Here's a procedure for renaming a branch tags: www.loria.fr/~molli/fom-serve/cache/83.html Recent cvs info nodes for Revisions/Modifying tags state: "Warning: Moving branch tags is very dangerous! If you think you need the -B option, think again....There is almost certainly another way to accomplish what you want to accomplish_" And that's for _moving_ tags. As far as I know, there is no easy way to duplicate a branch except by explicitly merging it, and that's not really a duplicate. The faqomatic entry talks about running admin on each file; that doesn't seem to be a reasonable option with Python.
-1 :-) I thought of two ways. First, make a release23-maint branch tag off release23-fork and merge release23-fork to it. The problem with this is it's a lot of work and loses/obscures the history on the original branch. Or, do it like 2.2 was apparently forced to do (*): Switch to release23-branch, tag [the head of release23-branch] as release23-maint-fork, and add a branch tag release23-maint. That's a lot easier, of course. And safe. -- KBK (*) Looking at patchlevel.h, for instance: release22-fork magic number branch 2.60.0.2 release22 this was the first tag on that branch: 2.60.2.1 release22-maint magic number branch 2.60.2.1.0.2 r221c1 third tag on _that_ branch: 2.60.2.1.2.3

Kurt B. Kaiser writes:
The problem we have with this is that it produces really horrid revision numbers with 6 places instead of 4. Appearantly modern versions of CVS work just fine with these, but... it makes our stomachs churn! (Er, that's *not* a good thing...) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Barry Warsaw <barry@python.org> writes:
I fail to see the problem. Python 2.2 also has release22-fork (a tag), release22-branch (a branch), release22-maint (a branch), and release22 (a tag). I don't know whether this was intentional or not, but I would interpret it this way: - release22-fork: Point where release procedure for 2.2 started - release22-branch: Branch on which 2.2.0 was developed - release22: the actual release - release22-maint: Maintenance (2.2.1, etc) I suggest to do the same for 2.3, i.e. cvs co -r release23-fork cvs tag -b release23-maint You will then need to merge the changes from release23-branch to release23-maint, which, I believe, is done by cvs co -r release23-maint cvs up -j release23-branch cvs commit In the future, I recommend to drop the release branch altogether. Instead, when RC1 is going to be released, create a -maint branch, and release RC1 off that, then release RC2, and the final release also from the -maint branch. Changes made to the -maint branch must then get forwarded to HEAD manually, but there shouldn't be many. Regards, Martin

On Fri, 2003-08-01 at 03:37, Martin v. Löwis wrote:
I think this is the right (and easiest) suggestion. While Fred's approach works, stewing on it overnight, it does seem like overkill. Right now, Jack owns the -branch, so I'm going to wait until Jack is done with the MacOS9 build and then I'll do this.
PEP 101 was written at a time when we had plenty of spare cycles to do releases. That isn't true any more so I've been slowly modifying it to today's reality. Right now, it makes no mention of -branch tags, cutting all releases (except final) from the trunk. When we're about to release the final, we cut a -maint branch and do the final release from there. rc's still get released from the trunk. I'm inclined to leave it this way. Orlijn will probably tweak it when he releases Python 2.4 <wink>. -Barry

[Mark Hammond]
Please do. I had hoped to do that, but a work crisis has me on the road and I won't be doing anything with Python this week.
Probably, but it doesn't matter <wink>. xyz-fork is just a tag on the HEAD, and xyz-branch is a branch that started life with the stuff with the xyz-fork tag.
Is there a branch that will track the "latest 2.3" for the next few years (ie, through 2.3.1, 2.3.2 etc?)
It doesn't appear that there is yet. Barry? It will be named release23-maint.

On Wed, 2003-07-30 at 21:35, Tim Peters wrote:
Well, here's the problem. The branch was already created with release23-branch, and there doesn't appear to be a way to rename a branch tag. Fred's going to dig into the docs to see if he can find a clue, but if anybody else has direct experience with renaming branch tags, please speak up! I've updated the pep so this won't happen again three years from now when Orlijn releases Python 2.4 <wink>. The other option is to just stick with release23-branch as the maintenance branch tag. -Barry

Barry Warsaw writes:
Boy have we dug! Did the nasty with a test repository as well.
The other option is to just stick with release23-branch as the maintenance branch tag.
Thomas Heller writes:
If these weren't branch tags, that would be exactly what we want. The CVS manual says this doesn't work for branch tags. It's right. Here's what we've come up with: 1. Create a fresh checkout from the release23-branch tag. Capture the cvs output (all the "U somefile" lines) for use in the next step. 2. Massage the cvs output to create input for xargs --null: sed 's/^U //' cvsoutput | tr '\n' '\000' >xargsinput 3. Use xargs --null to drive a cvs admin command: cat xargsinput | xargs --null cvs admin -N release23-maint:release23-branch 4. Send an email to python-dev to let people test. Note that the release23-branch tag is left alone. It's not worth the risk of removing it. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Barry Warsaw <barry@python.org> writes:
Although renaming ordinary tags is straightforward, (update to the old tag, tag with the new name, update to the new name, delete the old tag), this is not the case with branch tags. Here's a procedure for renaming a branch tags: www.loria.fr/~molli/fom-serve/cache/83.html Recent cvs info nodes for Revisions/Modifying tags state: "Warning: Moving branch tags is very dangerous! If you think you need the -B option, think again....There is almost certainly another way to accomplish what you want to accomplish_" And that's for _moving_ tags. As far as I know, there is no easy way to duplicate a branch except by explicitly merging it, and that's not really a duplicate. The faqomatic entry talks about running admin on each file; that doesn't seem to be a reasonable option with Python.
-1 :-) I thought of two ways. First, make a release23-maint branch tag off release23-fork and merge release23-fork to it. The problem with this is it's a lot of work and loses/obscures the history on the original branch. Or, do it like 2.2 was apparently forced to do (*): Switch to release23-branch, tag [the head of release23-branch] as release23-maint-fork, and add a branch tag release23-maint. That's a lot easier, of course. And safe. -- KBK (*) Looking at patchlevel.h, for instance: release22-fork magic number branch 2.60.0.2 release22 this was the first tag on that branch: 2.60.2.1 release22-maint magic number branch 2.60.2.1.0.2 r221c1 third tag on _that_ branch: 2.60.2.1.2.3

Kurt B. Kaiser writes:
The problem we have with this is that it produces really horrid revision numbers with 6 places instead of 4. Appearantly modern versions of CVS work just fine with these, but... it makes our stomachs churn! (Er, that's *not* a good thing...) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Barry Warsaw <barry@python.org> writes:
I fail to see the problem. Python 2.2 also has release22-fork (a tag), release22-branch (a branch), release22-maint (a branch), and release22 (a tag). I don't know whether this was intentional or not, but I would interpret it this way: - release22-fork: Point where release procedure for 2.2 started - release22-branch: Branch on which 2.2.0 was developed - release22: the actual release - release22-maint: Maintenance (2.2.1, etc) I suggest to do the same for 2.3, i.e. cvs co -r release23-fork cvs tag -b release23-maint You will then need to merge the changes from release23-branch to release23-maint, which, I believe, is done by cvs co -r release23-maint cvs up -j release23-branch cvs commit In the future, I recommend to drop the release branch altogether. Instead, when RC1 is going to be released, create a -maint branch, and release RC1 off that, then release RC2, and the final release also from the -maint branch. Changes made to the -maint branch must then get forwarded to HEAD manually, but there shouldn't be many. Regards, Martin

On Fri, 2003-08-01 at 03:37, Martin v. Löwis wrote:
I think this is the right (and easiest) suggestion. While Fred's approach works, stewing on it overnight, it does seem like overkill. Right now, Jack owns the -branch, so I'm going to wait until Jack is done with the MacOS9 build and then I'll do this.
PEP 101 was written at a time when we had plenty of spare cycles to do releases. That isn't true any more so I've been slowly modifying it to today's reality. Right now, it makes no mention of -branch tags, cutting all releases (except final) from the trunk. When we're about to release the final, we cut a -maint branch and do the final release from there. rc's still get released from the trunk. I'm inclined to leave it this way. Orlijn will probably tweak it when he releases Python 2.4 <wink>. -Barry
participants (8)
-
Barry Warsaw
-
Fred L. Drake, Jr.
-
Jeremy Hylton
-
kbk@shore.net
-
Mark Hammond
-
martin@v.loewis.de
-
Thomas Heller
-
Tim Peters