[vtk-developers] VTK 4.2.4 and VTK 5

[Ken Martin]

Hey Prabhu,

> Personally I have no concerns of moving to VTK 5.  My biggest problem
> is letting users of VTK-Python and MayaVi have a stable and working
> VTK that has all the features that they would want to use.  I
> personally always build off CVS but users who sometimes never even use
> VTK have to end up using VTK off CVS simply because critical fixes are
> *only* in CVS and in no release.  As you mention using VTK from CVS is
> not advisable.

In that type of situation, if they cannot use the latest release then I
would recommend tagging (or branching) the CVS VTK for MayaVi. Then you can
provide at least CVS instructions (and maybe a tar file) for a version of
VTK that works with MayaVi.

> My other major gripe is that this devel list is never told of new
> releases.  Only major releases (like 4.0) are announced on vtkusers
> and vtk-devel.  At no point of time am I sure of what is the latest
> release.  I have to look at the web site to figure that out.  If you
> did announce it please point me to an email on this list that was sent
> and I'll shut up. :)

The description of what is in VTK 4.2 was in earlier emails. The last
significant email was
http://public.kitware.com/pipermail/vtk-developers/2003-February/002316.html
which isn't really an announcement.

Regarding what is the latest release I'd recommend the FAQ which
specifically answers this question. 
http://public.kitware.com/cgi-bin/vtkfaq?req=show&file=faq01.002.htp

Having said that, I appreciate the basic idea that more communication would
be good. I have stopped posting as much partially because I didn't want to
generate too much noise. For example, in the past I would post CMake patch
release announcements to the vtk-developers list, but I stopped doing this
because it seemed like it wasn't critical to vtk-developers (possibly
interesting but not critical). I almost never announce VTK patch releases
although that is probably a mistake. I'll start announcing those from now
on.

>     KM> the VTK 4.2 branch of the main tree (different from the VTK4
>     KM> tree) is the latest release and if there have been critical
>     KM> fixes (not new features) made in VTK CVS then they should have
>     KM> been reported to me (or noticed by me) so I could merge them
>     KM> into the release. VTK 4.2 is the current release and is what
>     KM> most/all non developers should be using. If it doesn't work
>     KM> with Python 2.3 then that should have been addressed. Does
>     KM> that make sense?
> 
> Yes and no.  Its a problem of miscommunication.  As I said I usually
> have no clue of releases and have no idea of who is tracking what.
> Everyone seems to happily make changes without the slightest noise on
> the lists.  Only now was there talk of branching off before 5 with a
> bunch of impressive changes but since I am already lost about what
> releases are made I assumed that you'd branch off from where it
> currently is.  I also am not sure if there are a bunch of Mac OSX
> related fixes in 4.3?  The Mac issues are long running and I still am
> not sure which release I can point someone to who wants to use
> VTK-Python successfully on the Mac!  Those who do use seem to use VTK
> off CVS and I am not comfortable pointing everyone to use CVS.

Personally I'm not comfortable with the Mac changes. No real reason, I just
feel like the Mac and Python on the Mac are moving targets that haven't
matured yet. I'm concerned about putting out a release with those changes
because I lack confidence that they work and will continue to work into the
future. I don't even know if we really support pre jaguar OSX any more. My
gut reaction on this is to leave MAC to CVS until panther has been out for a
while and then require VTK users to use panther.

>     >> 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?
> 
>     KM> My guess is that VTK 5 will become stable around the middle of
>     KM> 2004. We will try to keep CVS stable but no average users
>     KM> should be using CVS. The point of having the releases (4.2)
>     KM> and patch releases (4.2.3, 4.2.4, etc) is to provide a tested
>     KM> stable version of VTK so that people who need a working
>     KM> version of VTK don't have to mess around with checking the
>     KM> dashboards. The only exception to this is when someone needs a
>     KM> new feature that is in CVS but not in the release. In those
>     KM> cases if it is a key feature that is unlikely to cause
>     KM> problems we will add it to the VTK 4.2 branch.
> 
> How do you define "key" feature?  How about the gl2ps stuff?  I asked
> about it before 4.0 and it would be sad if users had to wait till 5.0
> were released in mid-2004 to use it in a stable release.

It is a nice feature but I'd wait and let it be a part of the VTK 4.4
snapshot.

>     KM> Why not make a new release from what is in CVS right now?
>     KM> Because the release process takes a lot of effort and the
>     KM> amount of "added value" in VTK
>     KM> 4.3 doesn't warrant it in my opinion. I'd rather perform minor
>     KM>     updates to
>     KM> the 4.2 branch and put the effort into getting VTK 5 done.
> 
> I have a suggestion.  Instead of having an old stable release and a
> new unstable CVS version to deal with why not make interim snapshots
> along the lines of "tested to be stable but not perfect for a
> release".  Folks who need it can use these snapshots and will also get
> the benefit from recent additions and improvements?

We will have snapshots, but they will not be full releases. The FAQ etc will
still point to VTK 4.2 as the release but at least the snapshots will
provide points for people who need a recent but stable version of VTK. A
rough roadmap (I'll update the FAQ) is attached below:

VTK 4.4 (intermediate release, end of year)
  - convert APIs to double
  - remove old callbacks (mostly done but not checked in)
  - blanking (done I think)
  - ref count observers (done)
  - switch collections to use iterators
  - improve copyright (done)

VTK 4.8 (intermediate release, end of February)
  - create mesh class to combine polydata with ugrid
  - volume rendering changes (maybe in 4.4)

VTK 5.0 (major release, end of June)
  - new pipeline mechanism
  - time support
  - true AMR support

Ken