Nightly names with current release version are confusing

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”.

2 Likes

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.

1 Like

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.

I agree with @cory.quammen . What works for VTK (developper oriented) will not work for ParaView.

Then do we move to odd-minor is in-development and even-minor is a user-facing release? Make master 5.11 and release 5.12 in the spring?

You lost me there.

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?

Oh, I don’t like the scheme either. It was a reply to:

The version should still be included to avoid having to download and extract the tarball to figure out what each tarball contains. Would this work?

ParaView-nightly-5.10.0-451-g61c424a-MPI-Linux-Python3.9-x86_64.tar.gz

Note that the titlebar will not include the nightly without other code changes.

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?

Do these nightly builds use the VTK master as well?

I just wonder where we get that number from if we’re not committing it to the repository somewhere.

Whatever VTK is pointed to by the submodule. It moves roughly weekly (depending on the curve balls VTK ends up throwing ParaView’s way).

5.10-nightly-development perhaps?

Is there any way to determine that version from the tarball?

I just wonder where we get that number from if we’re not committing it to the repository somewhere.

My understanding is that the number actually change in this proposition.

I’m good with your proposal, Cory. Above my pay grade with regards to how to implement it.

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.

Can anyone think of any unintended consequences?

One big issue I can see is cmake check.

MAJOR=5
MINOR=11
PATCH=?

-1 ?
0 ?
preview ?

All cmake checks should keep working.

This means that the versioning scheme is no longer monotonically increasing. Once we have 5.11, what is 5.11.0 coming after?

1 Like