.gitlab-ci.yml

@@ -255,7 +255,7 @@ fedora39-java8:build:
     # The Java build extends the build time considerably.
     timeout: 4 hours
     variables:
-      VTK_JAVA_VERSION: 1.8
+      VTK_JAVA_VERSION: 8
     needs: []
 
 fedora39-java11:build:
@@ -2111,7 +2111,7 @@ macos-x86_64-java8:build:
         - .cmake_build_artifacts
         - .weekly_upload_only
     variables:
-      VTK_JAVA_VERSION: 1.8
+      VTK_JAVA_VERSION: 8
     timeout: 4 hours
     needs: []
 
@@ -2135,7 +2135,7 @@ macos-arm64-java8:build:
         - .cmake_build_artifacts
         - .weekly_upload_only
     variables:
-      VTK_JAVA_VERSION: 1.8
+      VTK_JAVA_VERSION: 8
     timeout: 4 hours
     needs: []
 
@@ -2159,7 +2159,7 @@ windows-x86_64-java8:build:
         - .cmake_build_artifacts
         - .weekly_upload_only
     variables:
-      VTK_JAVA_VERSION: 1.8
+      VTK_JAVA_VERSION: 8
     timeout: 4 hours
     needs: []
 

.gitlab/ci/configure_fedora39_java.cmake

-set(VTK_JAVA_SOURCE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
-set(VTK_JAVA_TARGET_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
+set(VTK_JAVA_RELEASE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
 
 include("${CMAKE_CURRENT_LIST_DIR}/configure_fedora39.cmake")
 

.gitlab/ci/configure_macos_arm64_java.cmake

-set(VTK_JAVA_SOURCE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
-set(VTK_JAVA_TARGET_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
+set(VTK_JAVA_RELEASE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
 
 include("${CMAKE_CURRENT_LIST_DIR}/configure_macos.cmake")
 

.gitlab/ci/configure_macos_x86_64_java.cmake

-set(VTK_JAVA_SOURCE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
-set(VTK_JAVA_TARGET_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
+set(VTK_JAVA_RELEASE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
 
 include("${CMAKE_CURRENT_LIST_DIR}/configure_macos.cmake")
 

.gitlab/ci/configure_options.cmake

@@ -44,7 +44,7 @@ configuration_flag(VTK_WRAP_PYTHON "python")
 
 # java
 configuration_flag(VTK_WRAP_JAVA "java")
-configuration_flag(VTK_JAVA_INSTALL "java")
+configuration_flag(VTK_BUILD_MAVEN_PKG "java")
 
 if ("$ENV{CMAKE_CONFIGURATION}" MATCHES "java")
   set(BUILD_TESTING OFF CACHE BOOL "" FORCE)
@@ -52,7 +52,7 @@ if ("$ENV{CMAKE_CONFIGURATION}" MATCHES "java")
   # Naming is <arch-platform> since some maven versions fail to properly parse
   # the artifact name when numbers are trailing in the classifer name.
   set(MAVEN_NATIVE_ARTIFACTS "darwin-amd;darwin-arm;linux-amd;windows-amd" CACHE STRING "" FORCE)
-  set(MAVEN_VTK_ARTIFACT_SUFFIX "-java${VTK_JAVA_TARGET_VERSION}" CACHE STRING "")
+  set(MAVEN_VTK_ARTIFACT_SUFFIX "-java${VTK_JAVA_RELEASE_VERSION}" CACHE STRING "")
   # Disable snapshots for tag releases and also when the env variable
   # VTK_JAVA_FORCE_RELEASE is defined through the Gitlab schedule pipeline UI.
   # Note that VTK_JAVA_FORCE_RELEASE is used to create/override VTK java

.gitlab/ci/configure_windows_vs2022_java.cmake

-set(VTK_JAVA_SOURCE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
-set(VTK_JAVA_TARGET_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
+set(VTK_JAVA_RELEASE_VERSION $ENV{VTK_JAVA_VERSION} CACHE STRING "" FORCE)
 
 set(VTK_MODULE_ENABLE_VTK_vtkvtkm NO CACHE STRING "") # Java Wrap errors in windows
 

.gitlab/ci/ctest_exclusions.cmake

@@ -584,43 +584,13 @@ endif ()
 
 if ("$ENV{CMAKE_CONFIGURATION}" MATCHES "^wasm64")
   list (APPEND test_exclusions
-    # WebGPU tests on wasm64 fail
-    "^VTK::RenderingWebGPUCxx-TestActorFaceCullingProperty"
-    "^VTK::RenderingWebGPUCxx-TestCellScalarMappedColors"
-    "^VTK::RenderingWebGPUCxx-TestComputeDoublePipelineRenderBuffer"
-    "^VTK::RenderingWebGPUCxx-TestComputeFrustumCulling"
-    "^VTK::RenderingWebGPUCxx-TestComputeOcclusionCulling"
-    "^VTK::RenderingWebGPUCxx-TestComputeOcclusionCullingResize"
-    "^VTK::RenderingWebGPUCxx-TestComputeModifyPointColors"
-    "^VTK::RenderingWebGPUCxx-TestComputeModifyCellColors"
-    "^VTK::RenderingWebGPUCxx-TestComputePass"
-    "^VTK::RenderingWebGPUCxx-TestComputePassChained"
-    "^VTK::RenderingWebGPUCxx-TestComputePassUniform"
-    "^VTK::RenderingWebGPUCxx-TestComputePipelineRelease"
-    "^VTK::RenderingWebGPUCxx-TestComputePointCloudMapper"
-    "^VTK::RenderingWebGPUCxx-TestComputePointCloudMapperColors"
-    "^VTK::RenderingWebGPUCxx-TestComputePointCloudMapperDepth"
-    "^VTK::RenderingWebGPUCxx-TestComputePointCloudMapperGeometry"
-    "^VTK::RenderingWebGPUCxx-TestComputePointCloudMapperResize"
-    "^VTK::RenderingWebGPUCxx-TestComputeTexture"
-    "^VTK::RenderingWebGPUCxx-TestLineRendering"
-    "^VTK::RenderingWebGPUCxx-TestLowPowerRenderWindow"
-    "^VTK::RenderingWebGPUCxx-TestPointScalarMappedColors"
-    "^VTK::RenderingWebGPUCxx-TestScalarModeToggle"
-    "^VTK::RenderingWebGPUCxx-TestSurfacePlusEdges"
-    "^VTK::RenderingWebGPUCxx-TestQuad"
-    "^VTK::RenderingWebGPUCxx-TestQuadPointRep"
-    "^VTK::RenderingWebGPUCxx-TestRenderWindowChangeDeviceLater"
-    "^VTK::RenderingWebGPUCxx-TestVertexRendering"
-    "^VTK::RenderingWebGPUCxx-TestWireframe"
-    "^VTK::RenderingWebGPUCxx-TestPointRendering_1"
-    "^VTK::RenderingWebGPUCxx-TestPointRendering_2"
-    "^VTK::RenderingWebGPUCxx-TestPointRendering_3"
-    "^VTK::RenderingWebGPUCxx-TestPointRendering_4"
-    "^VTK::RenderingWebGPUCxx-TestMixedGeometry_1"
-    "^VTK::RenderingWebGPUCxx-TestMixedGeometry_2"
-    "^VTK::RenderingWebGPUCxx-TestMixedGeometry_3"
-    "^VTK::RenderingWebGPUCxx-TestReadPixels")
+    # WebGPU tests fail in wasm64 architecture. The tests
+    # fail because of a bug in the library_webgpu.js file
+    # that is fixed in the commit https://github.com/emscripten-core/emscripten/commit/01f89dcd3cb505f3fdfa3b2bd3d4ef654c753f0a
+    # which is available in emsdk >= 3.1.72
+    # See this issue which tracks the emsdk version update.
+    # https://gitlab.kitware.com/vtk/vtk/-/issues/19523
+    "^VTK::RenderingWebGPUCxx")
 endif ()
 
 

.gitlab/issue_templates/new-release.md

@@ -25,19 +25,17 @@ git checkout @BASEBRANCH@
 git merge --ff-only origin/@BASEBRANCH@ # if this fails, there are local commits that need to be removed
 git submodule update --recursive --init
 ```
-    - If `@BASEBRANCH@` is not `master`, ensure merge requests which should be
-      in the release have been merged. The [`backport-mrs.py`][backport-mrs]
-      script can be used to find and ensure that merge requests assigned to the
-      associated milestone are available on the `release` branch.
+  - If `@BASEBRANCH@` is not `master`, ensure merge requests which should be
+    in the release have been merged. The [`backport-mrs.py`][backport-mrs]
+    script can be used to find and ensure that merge requests assigned to the
+    associated milestone are available on the `release` branch.
 
   - Make a commit for each of these changes on a single topic (suggested branch
     name: `update-to-v@VERSION@`):
-    - Assemble release notes into `Documentation/release/@MAJOR@.@MINOR@.md`.
-      - [ ] If `PATCH` is greater than 0, add items to the end of this file.
+    - [ ] Move release note files to `Documentation/release/@MAJOR@.@MINOR@` folder.
     - [ ] If `@BASEBRANCH@` is `master`, update the non-patch version in a
           separate commit (so that `master` gets it as well).
-    - [ ] Remove old release note files
-    - [ ] Update `.gitlab/ci/cdash-groups.json` to track the `release` CDash
+    - [ ] If `@BASEBRANCH@` is `master`, Update `.gitlab/ci/cdash-groups.json` to track the `release` CDash
           groups
     - [ ] Update `CMake/vtkVersion.cmake` and tag the commit (tag this commit below)
 ```
@@ -60,24 +58,29 @@ git commit -m 'Update version number to @VERSION@@RC@' CMake/vtkVersion.cmake
         extraction heuristics fail).
     - [ ] Get positive review
     - [ ] `Do: merge`
+    - [ ] If `@BASEBRANCH@` is `master` and `@PATCH@ == 0`, note the date this merge occurs, this is the SPLIT_DATE.
+      - It can be recovered easily if needed by running `git log --first-parent --reverse origin/master '^origin/release'`
     - [ ] Push the tag to the main repository
       - [ ] `git tag -a -m 'VTK @VERSION@@RC@' v@VERSION@@RC@ commit-that-updated-vtkVersion.cmake`
       - [ ] `git push origin v@VERSION@@RC@`
-  - [ ] Update `vtk.org/download` with the new release (email
-        `marketing@kitware.com` with filenames and hashes)
-      - [ ] Hashes can be found in the output of the `release-artifacts:upload` job
-  - Software process updates (these can all be done independently)
-    - [ ] Update kwrobot with the new `release` branch rules
-      (@utils/maintainers/ghostflow)
+  - [ ] If `@RC@` is `""`, Update `vtk.org/download` with the new release
+      - Hashes can be found in the output of the `release-artifacts:upload` job
+      - [ ] email `marketing@kitware.com` with filenames and hashes
+  - If `@PATCH@ == 0` Software process updates **these can all be done independently**
+    - [ ] Update kwrobot with the new `release` branch rules (@utils/maintainers/ghostflow)
     - [ ] Run [this script][cdash-update-groups] to update the CDash groups
-      - This must be done after a nightly run to ensure all builds are in the
-        `release` group
+      - This must be done after a nightly run to ensure all builds are in the `release` group
       - See the script itself for usage documentation
     - Deprecation updates (if `@BASEBRANCH@` is `master`)
-    - [ ] Update deprecation macros for the next release
-    - [ ] Remove deprecated symbols from before the *prior* release
-    - [ ] Update `VTK_MINIMUM_DEPRECATION_LEVEL` to be that of the *prior*
-          release
+      - This should be done as soon as possible after merging to not block development
+      - [ ] Update deprecation macros for the next release, use `VTK_VERSION_CHECK(@MAJOR@, @MINOR@, SPLIT_DATE)`
+      - [ ] Update `VTK_EPOCH_VERSION` to the day *after* the SPLIT_DATE
+      - [ ] Remove deprecated symbols from before the *prior* release
+      - [ ] Update `VTK_MINIMUM_DEPRECATION_LEVEL` to be that of the *prior* release
+    - Assemble release notes from `Documentation/release/@MAJOR@.@MINOR@` into `Documentation/release/@MAJOR@.@MINOR@.md`.
+      - This can be done during the release cycles but must be done before the full release
+      - [ ] Recover new .md files as they are being added during release cycles and incorporate them into a coherent release note.
+      - [ ] If `PATCH` is greater than 0, add items to the end of `@MAJOR@.@MINOR@.md` file.
 
 [backport-mrs]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/backport-mrs.py
 [release-mr]: https://gitlab.kitware.com/utils/release-utils/-/blob/master/release-mr.py
@@ -91,5 +94,7 @@ git commit -m 'Update version number to @VERSION@@RC@' CMake/vtkVersion.cmake
 /cc @ben.boeckel
 /cc @berkgeveci
 /cc @vbolea
+/cc @sankhesh
+/cc @mwestphal
 /milestone %"@VERSION@@RC@"
 /label ~"priority:required"

.kitware-release.json

@@ -4,6 +4,8 @@
     "maintainers": [
         "ben.boeckel",
         "berkgeveci",
-        "vbolea"
+        "vbolea",
+        "sankhesh",
+        "mwestphal"
     ]
 }

CMake/vtkModuleWrapJava.cmake

@@ -192,7 +192,7 @@ $<$<BOOL:${_vtk_java_hierarchy_files}>:\n--types \'$<JOIN:${_vtk_java_hierarchy_
     set(_vtk_java_java_source_output
       "${_vtk_java_JAVA_OUTPUT}/${_vtk_java_basename}.java")
     set(_vtk_java_parse_depfile
-      "${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/${_vtk_java_library_name}Java.dir/${_vtk_java_basename}.java.d")
+      "${CMAKE_CURRENT_BINARY_DIR}/CMakeFiles/${_vtk_java_library_name}Java/${_vtk_java_basename}.java.d")
     list(APPEND _vtk_java_java_sources
       "${_vtk_java_java_source_output}")
 

CMake/vtkVersion.cmake

@@ -6,7 +6,7 @@ set(VTK_MINOR_VERSION 4)
 # the date component is updated while it is in progress, the bump of the minor
 # version ends up conflicting with the patch version update.
 
-set(VTK_BUILD_VERSION 20241220)
+set(VTK_BUILD_VERSION 20250107)
 
 if (NOT VTK_MINOR_VERSION LESS 100)
   message(FATAL_ERROR

CMakeLists.txt

@@ -711,8 +711,15 @@ if (VTK_WRAP_PYTHON)
 endif ()
 
 if (VTK_WRAP_JAVA)
-  enable_language(Java)
+  find_package(Java 11 REQUIRED COMPONENTS Development)
+
+  # We need to set CMAKE_Java variables before enable_language to
+  # retain specified JDK in ENV{JAVA_HOME}.
+  set(CMAKE_Java_ARCHIVE ${Java_JAR_EXECUTABLE})
+  set(CMAKE_Java_COMPILER ${Java_JAVAC_EXECUTABLE})
+  set(CMAKE_Java_RUNTIME ${Java_JAVA_EXECUTABLE})
 
+  enable_language(Java)
   add_subdirectory(Wrapping/Java)
 endif ()
 

Common/Core/CMakeLists.txt

@@ -549,7 +549,7 @@ endforeach ()
 if (VTK_BUILD_VERSION LESS "20000101")
   set(VTK_EPOCH_VERSION "${VTK_BUILD_VERSION}")
 else ()
-  set(VTK_EPOCH_VERSION "20230101")
+  set(VTK_EPOCH_VERSION "20241009")
 endif ()
 
 set(nowrap_headers

Common/DataModel/vtkGenericCell.cxx

@@ -152,6 +152,7 @@ int vtkGenericCell::SetCellFaces(vtkCellArray* faces)
   if (!cell)
   {
     vtkErrorMacro("SafeDownCast to vtkPolyhedron failed, the cell is not a polyhedron");
+    return 0;
   }
   return cell->SetCellFaces(faces);
 }
@@ -163,6 +164,7 @@ vtkCellArray* vtkGenericCell::GetCellFaces()
   if (!cell)
   {
     vtkErrorMacro("SafeDownCast to vtkPolyhedron failed, the cell is not a polyhedron");
+    return nullptr;
   }
   return cell->GetCellFaces();
 }
@@ -174,6 +176,7 @@ void vtkGenericCell::GetCellFaces(vtkCellArray* faces)
   if (!cell)
   {
     vtkErrorMacro("SafeDownCast to vtkPolyhedron failed, the cell is not a polyhedron");
+    return;
   }
   cell->GetCellFaces(faces);
 }

Common/DataModel/vtkHigherOrderTetra.cxx

@@ -780,6 +780,14 @@ void vtkHigherOrderTetra::SetParametricCoords()
     double order_d = static_cast<vtkIdType>(this->GetOrder());
     this->PointParametricCoordinates->SetNumberOfPoints(nPoints);
 
+#ifdef ENABLE_CACHING
+    if (static_cast<vtkIdType>(this->BarycentricIndexMap.size()) !=
+      4 * this->GetPointIds()->GetNumberOfIds())
+    {
+      vtkWarningMacro(<< this->GetClassName() << " has not been initialized");
+      return;
+    }
+#endif
     vtkIdType bindex[4];
     for (vtkIdType p = 0; p < nPoints; p++)
     {

Documentation/docs/build_instructions/build_settings.md

@@ -31,9 +31,11 @@ Less common, but variables which may be of interest to some:
     available or not.
   * `VTK_WRAP_JAVA` (default `OFF`; requires `VTK_ENABLE_WRAPPING`):
     Whether Java support will be available or not.
+  * `VTK_JAVA_RELEASE_VERSION` (default `8`; requires `VTK_WRAP_JAVA`):
+    The version of Java in which VTK's Java wrapping will be built for.
   * `VTK_WRAP_SERIALIZATION` (default `OFF`; requires `VTK_ENABLE_WRAPPING`):
     Whether serialization code will be auto generated or not.
-  * `VTK_JAVA_INSTALL` (default `OFF`; requires `VTK_WRAP_JAVA`):
+  * `VTK_BUILD_MAVEN_PKG` (default `OFF`; requires `VTK_WRAP_JAVA`):
     Whether to build the Java Maven package for VTK.
   * `VTK_SMP_IMPLEMENTATION_TYPE` (default `Sequential`): Set which SMPTools
     will be implemented by default. Must be either `Sequential`, `STDThread`,

Documentation/docs/design_documents/VTKFileFormats.md

@@ -1087,7 +1087,7 @@ offset.
 
 ### Poly data
 
-The format for unstructured grid is shown in Figure 8. In this case
+The format for poly data is shown in Figure 8. In this case
 the `Type` attribute of the `VTKHDF` group is `PolyData`.
 The poly data is split into partitions, with a partition for
 each MPI rank. This is reflected in the HDF5 file structure. Each HDF

Documentation/docs/developers_guide/release_process.md

@@ -12,14 +12,19 @@ features.
 
 VTK releases are named with a `Major.Minor.Patch` scheme.
 
+VTK releases are handled by the VTK release group, which currently consists of:
+ - @vbolea
+ - @sankhesh
+ - @mwestphal
+
 ## Branching Scheme
 
 The overall release history resembles a skinny tree. Development proceeds along
 the `master` branch, consisting of topic branches that start from and are merged
 into `master`. Every so often, a release is tagged and branched from it.
 
-In general, no work takes place on the `release` branch, other than the handful
-of important patches that make up occasional patch releases.
+In general, no work takes place on the `release` branch, but some bug fixes from
+master can be backported and will be used for occasional patch releases.
 
 :::{hint}
 Steps for contributing changes specific to the `release` branch are documented in
@@ -36,11 +41,11 @@ The process for cutting releases is as follows:
 
 1. Announce upcoming release
 
-   A few weeks before the intended `release` branch, announce on [VTK Discourse](https://discourse.vtk.org/)
-   that a new release is coming. This alerts developers to avoid making drastic
-   changes that might delay the release and gives them a chance to push important
-   and nearly completed features in time for the release. For example,
-   see [this post](https://discourse.vtk.org/t/vtk-9-2-0-release-cycle/8149).
+   A few weeks before the intended `release` branch, the VTK release group
+   announce on [VTK Discourse](https://discourse.vtk.org/) that a new release is coming.
+   This alerts developers to avoid making drastic changes that might delay the release
+   and gives them a chance to push important and nearly completed features in time for the release.
+   For example, see [this post](https://discourse.vtk.org/t/vtk-9-4-0-release/14577).
 
 2. Polish the dashboards and bug tracker by addressing outstanding issue and
    coordinate effort with relevant developers.
@@ -48,6 +53,8 @@ The process for cutting releases is as follows:
    Persistent compilation and regression test problems are fixed. Serious
    outstanding bugs are fixed.
 
+   This is an effort involving the whole community of developers.
+
 3. [Create a new issue](https://gitlab.kitware.com/vtk/vtk/-/issues/new) titled
    `Release X.Y.Z[rcN]` based of the [new-release](https://gitlab.kitware.com/vtk/vtk/-/blob/master/.gitlab/issue_templates/new-release.md?plain=1) template.
 
@@ -56,6 +63,8 @@ The process for cutting releases is as follows:
    in the newly created issue.
    :::
 
+   This is handled by the VTK release group.
+
 4. Perform the release candidate cycle
 
     1. Tag the release branch and create and publish release candidate
@@ -72,12 +81,18 @@ The process for cutting releases is as follows:
     3. If the community reports bugs, classify them in the bug tracker and ensure
        they are fixed.
 
+       This is not handled by the VTK release group but by the whole community
+       of VTK developers.
+
        Only serious bugs and regressions need to be fixed before the release.
+       Such merge requests must be acknowledged (`+1`) by the VTK release group
+       before being merged.
        New features and minor problems should be merged into `master` as usual.
 
        Patches for the release branch should start from the release branch, be
        submitted through GitLab, and then merged into `master`. Once fully
-       tested there, the branch can be merged into the release branch.
+       tested there, reviewed and acknowloedge by the VTK release group,
+       the branch can be merged into the release branch.
 
        When the selected issues are fixed in the release branch, tag the tip
        of the release branch and release it as the next candidate, then the
@@ -108,7 +123,7 @@ The process for cutting releases is as follows:
    release for various platforms, so their input is especially valuable during
    the release cycle.
 
-   The release manager also compiles release notes for the official release
+   The VTK release group also compiles release notes for the official release
    announcement. Release notes are compiled from various [standardized topic documents](https://gitlab.kitware.com/vtk/vtk/-/tree/master/Documentation/release)
    added to the `Documentation/release/dev` folder while features or issues
    are fixed. The aggregation of these topic files is done manually and

Documentation/release/9.4.md

-# VTK 9.4.0 Release Notes
+# VTK 9.4.1 Release Notes
 
 Changes made since VTK 9.3.1 include the following.
 
@@ -351,6 +351,7 @@ Changes made since VTK 9.3.1 include the following.
     [Author's note](9.4/refactor-vtkCell-triangulate.md)
 - `vtkPolygon` triangulation implementation has been improved. [Author's note](9.4/vtkPolygons-quad-triangulation-quick-path.md)
 - Multiple improvements to VTK's polyhedral cell storage. [Author's note](9.4/vtk-polyhedral-cells-storage.md)
+- Fix cell-grid initialization crashing on static debug Windows builds. [Author's note](9.4/cell-grid-initialization.md)
 
 ### Filters
 
@@ -384,6 +385,7 @@ Changes made since VTK 9.3.1 include the following.
 
 - Multiple improvements have been made to the multi-touch event based gesture handling in VTK.
     :warning: **BREAKING_CHANGES** [Author's note](9.4/multitouch-gestures.md)
+- Fixed Cocoa (macOS) incorrect KeySym. [Author's note](9.4/cocoa-backspace-keysym.md)
 
 ### Python
 
@@ -408,6 +410,7 @@ Changes made since VTK 9.3.1 include the following.
 
     ![](https://www.vtk.org/files/ExternalData/SHA512/3c49faca41da626020e45a14b43b08412bbe200508e568930ee37374ae95f89d633bc9a4c6d4c7b211fffc4bc3ea6f47d42ee97dc3ce236dca389905de00ed05)
 
+- Fix deserialization bug in vtkCollection. [Author's note](9.4/fix-deserialization-bug-in-vtkCollection.md)
 ### System
 
 - `vtkSocket` can now bind to any user-specified address to restrict interfaces the