-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Jan 28, 2008, at 5:08 PM, Martin v. Löwis wrote:
Would it help if I branch branches/release23-maint/Lib/email to branches/email-2.3 ? Or should I branch the entire release23-maint to email-2.3? (branches are cheap in subversion) (*)
I just realized there's a good solution to this. The sandbox has an emailpkg directory with subdirectories for each of the email package releases. Currently, the actual code gets svn:external'd in from the Python branches, but for email 2.5 and 3.0 we should just svn copy the branches into here and remove the svn:external definitions. I'm not able to do this right now, but I should be able to do this in the next day or so if you don't beat me to it.
It would mean that you have to check in future 2.3 fixes of the email package into a different branch, and if you run into security fixes, you need to commit them into two branches (email-2.3 and release23-maint).
Using the above scenario, that would be fine.
Same for 2.4. For 2.5, bug fixes could be added until that branch also goes into the security-only mode (i.e. after 2.6 is released).
So for now, we'll leave email 4.0 external'd in from the Python 2.5 branch. When 2.6 is released, we'll svn copy that in like we did above. The only catch is that it would probably be best to rev the email package version number in Python 2.6 just to be clear it's a different branch. 4.1.0 would be a fine number even if it's mostly just a bookkeeping trick.
Please let me know what you think.
What do you think of the above?
Thanks! - -Barry