[Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0 (original) (raw)
M.-A. Lemburg mal at egenix.com
Thu May 29 16:51:25 CEST 2008
- Previous message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Next message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 2008-05-28 19:08, Bill Janssen wrote:
I'm beginning to wonder whether I'm the only one who cares about the Python 2.x branch not getting cluttered up with artifacts caused by a broken forward merge strategy. I share your concern. Seems to me that perhaps (not sure, but perhaps) the rush to back-port from 3.x, and the concern about minimizing pain of moving from 2.x to 3.x, has become the tail wagging the dog.
Indeed.
If the need to be able to forward merge changes from the 2.x trunk to the 3.x branch is the only reason for the current approach, then we need to find a better procedure for getting patches to 2.x forwarded to 3.x.
I believe that everyone is aware that 3.x breaks things and that's fine.
However, the reason for introducing such breakage in 3.x is that users have the option to decide whether and when to switch to the new major version.
Being able to play with 3.x features in 2.x is nice, but I wouldn't really consider those essential for 2.x. It certainly doesn't warrant causing major problems in the 2.x releases.
The module renaming backport was one example (which was undone again), the C API renaming is another. I expect more such features to be backported from 3.x to 2.x (even though I don't really think it's worth the trouble) and since this always means that changes have to applied in two worlds, we'll need a better process for getting changes in one major release ported to the other.
Simply tweaking 2.x into shape so that the rather simple minded SVN merge command works, isn't a good enough procedure for this.
That's why I suggested to use an intermediate form or branch for the merging - one that implements the 2.x with all renaming and syntax fixing applied.
This would:
reduce the number of merge conflicts since the renaming would already have happened
reduce the patch sizes that have to be applied to 3.x in order to stay in sync with 2.x
result in a tool chain that makes it easier for all Python users to port their code to 3.x
simplify renaming or reorg of modules, functions, methods and C APIs without requiring major changes on either side
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, May 29 2008)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2008-07-07: EuroPython 2008, Vilnius, Lithuania 38 days to go
:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611- Previous message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Next message: [Python-Dev] [Python-3000] Stabilizing the C API of 2.6 and 3.0
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]