ParaView versioning change

Hi all,

ParaView is consistently reaching the maximum file path limits on its Windows packaging builds. In order to help reduce this, there’s an idea to migrate to date-based versioning on master rather than git describe-based versioning. Example

Before: ParaView-master-5.12.0-RC1-NNN-gXXXXXXXXXX
After : ParaView-5.12.YYYYMMDD

where NNN is the number of commits since the named tag and XXXXXXXXXX is a unique git hash prefix. The YYYYMMDD part is updated every day on ParaView master to the current day. As you can see, this should give us at least 19 characters of breathing room (~7.5%) for our longer paths again (it could be more as the XXXXXXXXXX length depends on the size of ParaView’s history; currently Git uses 10 characters).

Note that non-master builds will continue to use git describe as otherwise all builds would appear as 5.12.0-RC1 which is too confusing.


  • Version number is ambiguous within a day. Not an issue with “I’m getting a nightly”, but could be confusing given MR and arbitrary master builds.
  • release builds and MRs will continue to fail to build Windows .msi binaries until the tag arrives and removes the -NNN-gXXXXXXXXXX suffix to make filenames short enough


  • Shorter version names.
  • master builds can complete .msi builds and test.
  • Deprecations on release versions can now fire on master as the deprecation macros can detect “5.12-relevant” from “will be 5.13” while keeping a monotonic property for versioning.

A prior discussion was had, but nothing was actually done post-5.11 at the time.

Implemented here:



1 Like

Participants in the prior discussion: @cory.quammen @wascott @mwestphal @Andrew_Maclean @todoooo @danlipsa @nicolas.vuaille

If the Windows path names are getting too long isn’t using a symbolic link a possible solution?

Shorter CI paths would help, but we’d also (probably) have to reset our caches. Ideally we’d have WiX support long paths and not need to worry about it ever again. That comes with WiX 4, but CPack doesn’t support it yet.

Just being able to do date based comparison of ParaView when using ParaView in a plugin or a ParaView-based application is enough to justify the switch.

Actual testing of deprecation is nice too.

1 Like

Is there a way to include the SHA somewhere, even if its not used as a version? That will eliminate any confusion if we have to track the source for a certain binary.
Maybe have
ParaView-5.12.YYYYMMDD for files
but also have
somewhere in the code. We don’t have to use the last part for version comparisons.

Would the SHA-1 still be in the About dialog? That would be good enough IMO.

I’m OK with Ben’s suggestion. I think it gives plenty of resolution for reporting bugs to Kitware. Another idea would be to add the sha into the source code’s versions.txt file, but not use the sha for paths?

I made an MR to make VTK have a smaller rebuild on its date-based patch changes:

We can do the same with ParaView where the “quick” header is enough for preprocessor (deprecation) purposes but we get the full version for specific instances where it is truly needed (such as the About dialog or title bar management).

1 Like

I’ve rebased and update the updated the date in the MR. I plan on merging it tomorrow if CI comes back green.

This has been merged and the first nightlies with this versioning scheme have been uploaded.

1 Like