BJ,
Not too sure which direction you applied from, trunk to release or release to
trunk?
I don't believe backward compatibility is relevant here.
Release 4.0 is not required to be backward compatible with trunk, nor vice
versa.
The trunk is a special branch. It forges ahead at high speed. All that is really required for
*any* revision in trunk is this: the ability to compile and function correctly (bugs aside).
However, in some cases, special consideration and extra effort could be spent on maintaining
backward compatibility, even in trunk revisions. In general, cases like say "many folks are using
JPublish" (not really true, just illustration), then the trunk would keep JPublish codes.
If you're into computer hardware, consider backward compatibility in the AGP (graphics port). An
AGP 8 slot can accommodate an AGP 8 or older (say AGP 4) graphics card. The analogy ties to the
release branch 4.0, where 4.x is compatible with 4.y.
Consider the trunk as the forefront of graphics card slots. The PCIe slot is completely
incompatible with AGP graphics cards. For the sake of progress, the PCIe inventors couldn't wait
for AGP graphics cards to all die off.
The jump from AGP to PCIe is too substantial to make backward compatibility possible. Same for 1.4
to 1.5, I believe. Sometimes, it takes so much to wait up for signs and omens to ratify the jump,
it's easier to just make the jump and be done wit it.
Jonathon
BJ Freeman wrote:
I just plugged my code from ver 4.0 into trunk
guess what
none of it works.
so what happend to depreciating then removing, based on releases.
Sure ver 1.5 has lots of neat things.
but shouldn't we try to conserve as much of the programming effort as we
can.
Why not add the same functions and method and leave the 1.4 compatibility
