Could we have a new VTK 9.x release soon?

Development
1

Hi all,

While tracking down something recently, I noticed the current VTK release (9.0.1) doesn’t actually compile out-of-the-box on recent macOS / Xcode because of:

/VTK-9.0.1/ThirdParty/hdf5/vtkhdf5/src/H5Fsuper.c:1397:16: error: implicit declaration of function ‘vtkhdf5_H5O__fsinfo_set_version’ is invalid in C99
[-Werror,-Wimplicit-function-declaration]
if(H5O__fsinfo_set_version(f, &fsinfo) < 0)
^

This is fixed in the release branch already.

We recently merged another HDF5 change in the release branch that allows VTK to be built as a Universal Binary on macOS.

Between those two issues, it would be great to have a new release. It never looks good to new users when something doesn’t compile out-of-the-box. :slight_smile:

Cheers,

Sean

2

Yes can I add my voice to this as well, I’m looking to upgrade from an old QT and ancient VTK to QT5 and VTK… something? What version? I don’t know!

I checked the git repo, and there isn’t even any branches for version 8 hotfixes?
It seems like VTK has leaped into a continuous release model?

I haven’t found any documentation or real discussion around when 9.0.2 or 9.1.x is planned for release.
I did see some discourse from last year about 9.1 rc, with the deadline in October 2020,
what happened there? I haven’t found any follow-up discussion.

There seems to be a lot of API changes in the pipeline, how are others keeping their codebase stable? There are so many merge requests, must be a lot of thrash on the master?

And what is the “release” branch for exactly? Is this a “more stable” version of master?

I’m wondering if I should just be branching of version 8.20 …

Thanks,
Paul

3

I should also mention that this would be a good page to document the release plans:
https://vtk.org/Wiki/VTK/Roadmap

hasn’t been updated for 9.x at all yet …
If this approach has been abandoned, then some notes/suggestions/tips for new developers would be really helpful in that page…

4

Point made: It may be time for a hackathon so we can figure out how to better plan for and communicate about the roadmap etc.

There seems to be a lot of API changes in the pipeline, how are others keeping their codebase stable? There are so many merge requests, must be a lot of thrash on the master?

The point of running thousands of tests on multiple platforms on a continuous basis has the effect of keeping the software relatively stable. While the process is far from perfect, the fact that the current level of development is going on continues to astonishes me, especially considering that Ken and I cut the first lines of VTK code in December 1993 - coming up on 30 years now…

5

What version? I don’t know!

Use the last released version, 9.0.1

There is no hotfixes for previous version of VTK.

There seems to be a lot of API changes in the pipeline, how are others keeping their codebase stable?

Every single API changes implies a legacy code to ensure retrocompatibility. This is part of the VTK code guidelines.

There are so many merge requests, must be a lot of thrash on the master?

Each merged Merge Request is reviewed and merged by experienced members of the VTK community.

And what is the “release” branch for exactly? Is this a “more stable” version of master?

The release branch is used for new patch release (eg: 9.0.2 if it ever comes) and only contains bugfixes, it does not contains new features as master does.

I’m wondering if I should just be branching of version 8.20

You definitely should not. the VTK 9 breaking changes are for the better.

I should also mention that this would be a good page to document the release plans: hasn’t been updated for 9.x at all yet …

Indeed, the wiki is being phased out. You can find documentation about the VTK 9 changes and release notes here: VTK 9.0.0 - #6 by ben.boeckel

That being said, we definitely needs to improve and clarify this process.

Are you a VTK contributor @Paul_Harris ? Maintaining and improving a opensource project as complex a VTK is a very big task and we will take any help we can get.

6

Yes it’s an amazing project, and great to see there are still major changes from time to time - keeping it fresh.

I think I started working with VTK in 2008, mostly as a vis library.

7

Hum how did you reply inline Mathieu?
via email, I guess? Discourse doesn’t seem to have an inline reply button?


|
|

  • | - |

What version? I don’t know!

Use the last released version, 9.0.1

That is pretty old, and I want to avoid hitting old bugs that have since been fixed over the last 8+ months…

I saw a few bug reports that are in the release/master that could affect me - hard to tell.
Plus I may have a few patches to push up.

And what is the “release” branch for exactly? Is this a “more stable” version of master?

The release branch is used for new patch release (eg: 9.0.2 if it ever comes) and only contains bugfixes, it does not contains new features as master does.

I should also mention that this would be a good page to document the release plans: hasn’t been updated for 9.x at all yet …

Indeed, the wiki is being phased out. You can find documentation about the VTK 9 changes and release notes here: https://discourse.vtk.org/t/vtk-9-0-0/3205/6

Thanks, I’ll track that thread.

That being said, we definitely needs to improve and clarify this process.

Even just cleaning up old links on the wiki might help in the meantime.
For example, I noticed there was a link to the old bug tracker that doesn’t work.

Are you a VTK contributor @Paul_Harris ? Maintaining and improving a opensource project as complex a VTK is a very big task and we will take any help we can get.

I have contributed over the last (nearly) 2 decades, with a few small patches and bugfixes,
but they have mostly been lost in the bug tracker and not folded in due to lack of attention.

I don’t have time to do any extra contributions or work for the VTK cause specifically, but if I do need to patch VTK, I will be pushing patches / pull requests as best I can.

8

Just select the text and then click Reply.

That is pretty old, and I want to avoid hitting old bugs that have since been fixed over the last 8+ months…

I saw a few bug reports that are in the release/master that could affect me - hard to tell.
Plus I may have a few patches to push up.

Then use master

9

I think it’s fair that Kitware focuses their resources on the master and release branches, and not on release-8.2 or release-7.1 etc. But as a community that is larger than just Kitware, with a fair number of members that have a real need to maintain the older branches, we really need to form a special interest group to look for solutions.

I’m in a similar situation as Paul. I’ve often had to backport patches to old versions of VTK, and I’d love to have a platform to share these patches. Surely there are enough of us in this situation that we can find a way to pool our resources? I’m envisioning something simple, like a vtk-backports github repository where these old branches can live. Each old branch can have a maintainer, someone from the community whose responsibility it is to ensure the stability of that branch. Kitware doesn’t have to be involved unless they want to be.

Any opinions?

10

I still don’t know how you reply inline to a previous post on discourse!

re David’s suggestion of a vtk-backports, it could be a fork but then it is hard to find and you may not get a critical mass of contributors… or kitware could give a few maintainers push-permissions to a branch, named something like “unofficial-backports-8.2” or something like that.

11

What about test servers for those branches?

12

I don’t expect that there would be any. Backport branches would not be for active development or for rolling releases. A person would pull from a backport branch because they need a fix for a legacy application. And that person/organization should have procedures in place for testing their legacy apps before redeployment.

In my view, the point of a backport branch is to share patches, not to produce new releases of old versions of VTK.

13

Paul, inline replying, or even quoting don’t work for me either. It just seems to swallow anything that’s a quote. I think it only works if you use the discourse webpage, and doesn’t work from email. :frowning:

Todd, what about test servers in general? Looking at cdash, I don’t see anyone but kitware and Rogue Research (me) running any test builds at all. There was definitely more years ago.

14

I’m in there too! Look for the machine “beck” in the nightlies. Though I do an awful job of maintaining it…

15

Inlining replies - Doesn’t work on the webpage for me either.

I’ll probably try and use the release branch, so i have no opinion on testing backports.

But at least if you have a backports branch, it provides a place for users on older releases to find each other and discuss things.

And would perhaps be a good place to help people upgrade to v9.
Ie tagged issue threads on gitlab or something.

16

We also should really either remove the old wiki,
or make notes on each page about which version the examples are appropriate for.

For example:
https://vtk.org/Wiki/VTK/Tutorials/CMakeListsFile

This hasn’t been correct for years now…

17

Hmm, now I have no idea.
I see a message that VTK_USE_FILE is no longer used since 8.90,
but,
the current vtk.git/Examples/Tutorial/Step1/Cxx/CMakeLists.txt
still has VTK_USE_FILE …

I found the new method here:
3645 topic
Would be great if it were documented and examples updated etc, or at least drop a readme in there that is blindingly obvious to find. There might already be something in there, but I might be more blind than most…

18

See the new VTK Examples website: https://kitware.github.io/vtk-examples/site/

The Examples within VTK itself should be cleaned up/

19

The wiki is being phased out.

20

I’ve started on 9.0.2 and want it done by the end of the month. There are no plans for a new release from master at this time though. I’ve gone through and added all MRs in release since 9.0.1 to the milestone I added at least. If there are any other changes, please get them up sooner rather than later. The only thing that I’m waiting for is this MR which adds macOS arm64 wheels which I’ll then backport once it works.

It will be a high bar for anything else: compile failures, platform support, or other similar things. No new APIs or features otherwise.

5 Likes