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.
Downsides:
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
Upsides:
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.
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.
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
ParaView-5.12.YYYYMMDD.gXXXXXXXXXX
somewhere in the code. We don’t have to use the last part for version comparisons.
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?
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).