Release versioning is inconsistent about nomacs HOT 7 OPEN

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

from nomacs.

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.

from nomacs.

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.

from nomacs.

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

from nomacs.

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.

from nomacs.

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.

from nomacs.

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.

from nomacs.