[vtk-developers] VTK 4.2.4 and VTK 5

[Prabhu Ramachandran]

>>>>> "KM" == Ken Martin <ken.martin at kitware.com> writes:

[snip]

    KM> 1) VTK 5 soon to be developed on the main tree
    KM> 2) VTK 4.2 release continues to be a branch on the main tree
    KM> 3) VTK4 tree supports future development and expansion of VTK
    KM>    4.2 for those
    KM> who don't want to go to VTK 5 but cannot stick with the 4.2
    KM> release

    KM> Comments, Questions, Flames, etc ???

A few thoughts (might end up being flames though).

 1. There are Python related issues that were fixed in the recent
    past.  Wrapping/Python/vtk/tk/vtkLoadPythonTkWidgets.py does not
    work under Python2.3 because the darned Python developers changed
    Tkinter behavior so that interp.getvar('auto_path') returns a
    tuple instead of a string.  These do not show up in the 4 tree and
    consequently you can't use the Tk widgets with VTK 4.  Serious
    pain in the neck.  Similarly there were the dlopen related fixes
    made to Wrapping/Python/vtk/__init__.py that don't show up in that
    tree.

 2. I am not for tracking yet another branch (due to lack of disk
    space and time), so am not volunteering to even make the changes
    on the 4 branch.  I would have appreciated if we were informed
    before the branch was made so I could have told you about this.

When will 5 become stable or when will 4.4 be released?  Without a
serious timeline its going to be a pain for users to decide which
release/version to use.  How unstable will CVS be?  Checking the
dashboards is too much work for the average user.  Its a bit much
asking users to even build VTK, asking them to track CVS is worse.
Also what is wrong with the current 4.3 tree, without backwards
incompatible changes?  Why not make that the default, let it stabilize
and branch off from there?

As a related (but off topic) point I think it makes sense to set
CMAKE_SKIP_RPATH to ON by default.  I've created a FAQ entry and
answered my fair share of the same question over and over again.  Too
many Python users are bitten by this.  Unless someone either offers
their time to handle all these requests or comes up with a better way
to solve the problem, I don't think I'm willing to accept it being
OFF.

prabhu