Why do we include the number of the currently released version in nightly builds of ParaView? Why not just “nightly” instead of “5.10.0-RC2”, for example?
The problem with including the version number is that it suggests the nightly is a build of some later version of the previously released version, not from the latest master. As a consequence, one may mistakenly assume features that are in the nightly from the master branch will be in the version referenced in the name, but that is quite often not the case.
Ignoring implementation details for now, how about replacing the most recent version string with “Nightly”, e.g., “ParaView Nightly-ga5e1ddfed5”? Or the branch name to accommodate release branch binaries, e.g., “ParaView Nightly Release-gabcdef1234”.
I totally, totally agree. How about ParaView-Nightly-master-ga5e1ddfed5 or even ParaView-Master-ga5e1ddfed5. Do we even need to say nightly, as that is already the page chosen on the download website? Last, as this is really always master, how about just ParaView-ga5e1ddfed5 on the nightly download page?
This has been bothering me for a while. I think having the branch name in the name make sense and could help if we have nightly of other branches for some reasons.
How about just bumping master to be 5.10.100? VTK does bump the patch to be date-based; 9.1.20220106 is used, but this means the version number changes every day; the version should be suitably hidden from that churn, but I don’t know if ParaView’s is.
If we decide to do this, an entry in the release process should be to make an MR bumping version.txt post-rc1 branching.
I had assumed that under the heading Release Candidates anything with “5.10.0-RC2” actually meant Release Candidate 2 for ParaView 5.10.0. The date on the file e.g. “2021-12-22 19:26” also gives the impression that its a Release Candidate since ParaView 5.10 was released on “Dec 22 20:48”. So I was monitoring these for changes. The line: “Previews of ParaView’s next release.” also tends to reinfrforce that impression. I didn’t realise that some features here would never appear in the Release 5.10 as it was frozen a few months back.
The would keep the major.minor version number, which is the source of confusion, and adding an arbitrary 100 in the patch number will just add to that I’m afraid.
Ben, NO. To users, we want the versions to make sense, and flow in a contiguous manner.
(Mathieu, Ben’s question is should odd versions be used for master, such as 5.1,5.3, 5.5, 5.7, 5.9, 5.11 and even be used for releases such as 5.6, 5.8, 5.10, 5.12, etc.)
So, again, why not just leave everything as is, except the tarball name for nightly? I believe it is the tarball name that is the primary issue. Drop the version, and if desired, add nightly?
Almost. Change 5.10 to 5.11-preview to make clear that this is leading up to 5.11 and not representative of anything in 5.10, and I like it. We could even drop the nightly from the name. What do we think?
Correct - just bump the version in version.txt to 5.11-preview. It would be easy to do that, at least. Can anyone think of any unintended consequences? PV-based apps might need to update version numbers they need to know about.
There is a version.txt file in the ParaView source files that contains only the version number in plain text.