Release versioning is inconsistent

[IdrisQe]

So, something I noticed when getting the latest Beta release is that the versioning is inconsistent. There are 3 different versions stated at different places... 3.17.2295 and 3.17.2297 are both shown on the release:

And when Windows User Account Control asks me if I'm sure I want the setup to make changes to my computer, if I click the "more details" button, it shows the version as 3.17.2296:

Judging by the commits, it looks like 2297 is actually version 2295, as the version number was upped to 2296 in a commit after the 2297 release (see why this is confusing?). I get that this is pedantic but this could become a legitimate point of confusion for users reporting issues if this trend continues. (Notably the version labelled 2.17.2289 is also tagged 2.17.2287 on the releases page - this isn't a one-time occurance)

[scrubbbbs]

@novomesk is this from the incrementor in cmake? Maybe we should disable this and bump the version manually when it makes sense to do so. The incrementor is currently force-enabled by in CMakeLists.txt and can't be turned off without modifying it, which is also annoying.

I would prefer to drop the build number and use git commit id to trigger any "there is a new version" detection. Since the commit id is the true version.

[leejuyuu]

I also agree that the autoincrement should be disabled. Here's some thoughts:

• New version detection can be done by using the github release. There's a latest endpoint that will always point to the latest release.
• We can adopt sementic versioning. It's going to look similar like what we have now, but the last number (patch) only increases when we manually tag it instead of increase for each build. This way we also can release less frequently.
• One problem would be the version of the plugins. I believe currently the windows installer ships with some of them? We can probably separate the versions of nomacs itself from the plugins. The plugins that are always included can be moved into the main repo. The other plugins have their own versions, and we do not include them when releasing nomacs. A separate widget could be made to allow installation of those plugins.
• We probably also need a release branching method. This method allows keeping to semver, allows maintenance to previous releases, and development on the main/master branch.
  • All the PRs still merge to main, including features and bug fixes
  • When we feel features on the main branch stable enough, branch into a new release branch (like 3.18) and tag minor release.
  • Because new features only gets merged to main, their instability will not affect release branches.
  • When we encounter bug fixes that can be ported back to previous releases, we can cherry-pick them to the release branches. Then tag patch releases periodically.

[novomesk]

If we disable autoincrementer, how do we distinguish between different builds from the same tag/commit?

Each time you re-build the same source, you may get different result. Dependencies, build environment may change meanwhile.

[scrubbbbs]

If we disable autoincrementer, how do we distinguish between different builds from the same tag/commit?

Maybe we don't have to, I think that's idea here. Has there been a situation where this has been useful? If it is just speculation and causing confusion it can be dropped.

Each time you re-build the same source, you may get different result. Dependencies, build environment may change meanwhile.

This is 100% true and a problem, but an incremented build number doesn't tell us what changed about the environment, or if it changed at all. Only that it might have changed, which isn't particularly useful.

If we do need to have a build identifier, I feel the best way is to bake the environment details into binaries and show them in the about box. They could also be hashed together for easy validation. The environment hash + git commit would then give a useful identifier.

As far as what details, we can probably catch 90% of issues with:

• cmake version and command line
• Library versions at compile-time for anything we use directly (Qt, OpenCV, Exiv2, etc)
• Compiler, it's version, important compiler flags (optimization level, debugging enabled)
• Compiler architecture codegen settings -- a common issue is non-generic instruction set (e.g. AVX512) gets into the build

[leejuyuu]

an incremented build number doesn't tell us what changed about the environment, or if it changed at all. Only that it might have changed, which isn't particularly useful.

I agree with this.

I feel the best way is to bake the environment details into binaries and show them in the about box.

I think we might only need OS and dependencies versions, which can be obtained from library headers. I'm not sure whether cmake and compiler settings will be useful when reporting issues. I like how inkscape is doing this. They don't actually show these info in the about, only the inkscape version is shown. The detailed info is hidden in a copy button, which contains

Inkscape 1.3.2 (091e20ef0f, 2023-11-25, custom)

    GLib version:     2.80.2
    GTK version:      3.24.42
    glibmm version:   2.66.7
    gtkmm version:    3.24.9
    libxml2 version:  2.12.6
    libxslt version:  1.1.39
    Cairo version:    1.18.0
    Pango version:    1.52.2
    HarfBuzz version: 8.5.0

    OS version:       Arch Linux

The build number is actually only relevant to the releases, because anyone who can grab a revision of the source code can attempt to build in an arbitrary environment and increase the build number. Using auto-increment build number does not help communication as it can conflict and it does not capture the actual environment info. Therefore, the build number should be attached to the released artifacts, and only the nomacs maintainer should increase the build number.

The windows version is kind of special because all the libraries nomacs depend on are packaged into the installer (please correct me if I am wrong). As the installer only comes from the CI environment, which we control, it is possible to ensure the build will be reproducible at a specific commit. If we can do that, then build number will not be required.

On Linux, the dependencies are usually dynamically linked, and every distro might have a different version of the same library at a point in time. We will never be able to control these. So, the build number will be useless because each system builds differently. Also, some distros add patches when creating packages.

Therefore, I think it's best to only version the source code, and capture the versions of the major dependencies.

[novomesk]

Often, it is needed to make a new revision of the installer. There are all kind of problems everywhere. Even the build tools changes over time. Not everything is in our source code.

When we do it without changing any number, some people will start to complain that the binary changed without increasing any number.

[leejuyuu]

Aren't the installer config/scripts part of this repo? If it's part of the git history, we can use semver to track it. It should be possible to pin the image used in CI, so the build tools would not be changed unless we change them.

[leejuyuu]

The autoincrementer has been disabled in https://github.com/nomacs/nomacs/commit/84abf78671f14d25a47cba678331dcfa46301d9f. Let's close this.