Maybe the confusion is that it is not clear if this nightly is before 5.10 or after 5.10:
ParaView-5.10.0-454-g5ee5bdfe50-MPI-Windows-Python3.9-msvc2017-AMD64.exe
How about if we rename this as:
ParaView-after-5.10.0-454-g5ee5bdfe50-MPI-Windows-Python3.9-msvc2017-AMD64.exe
or
ParaView-nightly-after-5.10.0-454-g5ee5bdfe50-MPI-Windows-Python3.9-msvc2017-AMD64.exe
Using the next version would mean that we know ahead of time what the next version is.
Is it 5.11 or is it 5.10.1?
Dan
That fixes the tarball, but the titlebar and about dialog won’t know that.
Depends on which branch you’re on 
.
This gives me the idea: why not just put the branch name after ParaView? The build can extract this information easily enough (tarballs are out-of-luck, but that’s not new for untagged releases) and put it into the title bar too. Examples:
ParaView-master-5.10.0-454-g5ee5bdfe50
ParaView-release-5.10.0-10-gdeadbeef
This is an improvement. Let’s try it.
MR for ParaView’s titlebar: https://gitlab.kitware.com/paraview/paraview/-/merge_requests/5440
See results here (word wrapped; the newline in the middle is just a space): https://gitlab.kitware.com/paraview/paraview/-/jobs/6494437#L1108
MR for ParaView superbuild to rename the package: https://gitlab.kitware.com/paraview/paraview-superbuild/-/merge_requests/953
Results will be here: https://gitlab.kitware.com/paraview/paraview-superbuild/-/jobs/6494585
No, there isn’t. It could be dropped in there through the source tarball generator script. Dropping it for all submodules would be handy. But, it is gnarly in there; git archive and submodules work as well together as two rabid territorial badgers in a tiny cage.
Some time have passed and I think we should revisit this topic.
As we have seen, our versionning system system is not working super great during RC period, with the nightly release being named: ParaView-master-5.11.0-RC2-211-g115116db37
Of course, the master is a good improvement but still, this code has nothing in common with the RC process.
Another thing I remarked in the last few months is that VTK current versionning system, with the nigthly push of the data as the patch is very very useful for application developers, and ParaView being as much a framework as it is an application, I wished for this feature in ParaView a few times this year.
So here is my suggestion:
Hypothetical ParaView 5.11.2 is out.
During standard developement time:
On the split:
During RC developement time
This way, we get the nice numbering system in the nightly release AND for applications developers.
The only things to do to get this is to setup the robot as with VTK and to add a small step in the release process.
The nightly release would for example be named:
ParaView-master-5.12.20221025-212-g115116db38
I thing we should still keep the branch name there anyway.
I’m not sure to follow why master will keep beeing 5.11XXX stuff and not 5.12XXX. We are after 5.12 feature freeze.
Typo, fixed.
I think the utility of the -212-g… bit is lost when the patch has a date number in it. Or at least the -212; the -g… bit can be handy (though we can probably use just 4 or 5 at that point since it’s pinned to a narrow date range at that point anyways).
I agree about the -212, I’m perfectly ok to remove it unless it matters to someoneelse.
The only point of it would be to identify at a glance that a nightly is after or before another nightly, but the date also contains this information for anyone that know how a calendat works
The only thing that I will insist on is that the nightlies remain sorted by creation date, and of course are unique. A few years ago the nightly list was not sorted, and it caused all kinds of confusion. Other than that, I’m good with any thing you propose.
I think this proposal is good. Who will implement the changes?
Brad pointed me to where the robot does this for VTK and CMake. I’ll implement it for ParaView as well. There will likely be some metadata extraction changes that will need to be done, so I’ll hold off until after 5.11.0 to avoid upsetting any applecarts.