On Fri, 2003-08-01 at 03:37, Martin v. L=F6wis wrote: > I suggest to do the same for 2.3, i.e. >=20 > cvs co -r release23-fork > cvs tag -b release23-maint >=20 > You will then need to merge the changes from release23-branch to > release23-maint, which, I believe, is done by >=20 > cvs co -r release23-maint > cvs up -j release23-branch > cvs commit 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. > 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. 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4