The meaning of version numbers can vary across projects.
One common scheme is Semantic Versioning, which divides the version number into three parts:
MAJOR.MINOR.PATCH*MAJORis incremented when there are backwards incompatible changes.MINORis incremented when new features are added in a backwards compatible way.PATCHis incremented for smaller big fixes.- Each number is reset to zero when a higher level number is incremented.
* It’s a bit more complex than this, but this is the gist.
While there are usual practices and some common sense methods you can expect, it is ultimately up to the software authors and can be whatever they wish, or nothing at all. Neither version nor build numbers are universally used.
AFAIK, build numbers and version numbers are usually seperate: Versions follow builds not the other way around.
You can build the same version multiple times. And no, versions are usually tied to branches and if you have a build pipeline for each supported branch, the builds most definitely follow versions. Perhaps you are confusing versions with releases?
You can build the same version multiple times
In theory shouldn’t they be the same unless parameters have changed?
I’m not following your point. When I say build the same version multiple times, I basically mean rerun the build. Maybe there was a bug in the build but the code isn’t changing. Each time you kick off the build for that pipeline, you will get a new buildid. Even if you change nothing and rerun a build, the build artifacts will likely not be identical. Even just an embedded datetime somewhere can make then not identical.
At some point, the latest build that has gone through your QA process will declared “ready” and promoted to release a.b.c. It’s imperative that you do not run separate build for release.
Why? Because you have a brand new set of artifacts and all the testing you did previously is now out of date and you need to retest everything.
Listen, I’m a Nix person.
I don’t understand how it works in whatever system you use or any other system, but here’s how I understand about this.
A Nix build/derivation is labeled by the hash of all the variables put into building it.
For example, compiler flags, config, architecture, which version, etc.
It is stored in the format
/nix/store/[Hash]-[Derivation Name]-[Version Number]/.Example:
/nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1/If I wanted to grab a particular build, I just request to some git repo or Nix cache and just let Nix install it, or if there isn’t a pre-built version, Nix can compile with the exact variables.
At the end, Nix can compare the hashes between what the source says and what it built/installed.
If there are new artefacts, Nix will create a separate derivation with a different hash.
Each time you kick off the build for that pipeline, you will get a new buildid.
You shouldn’t be able to rerun the same build with different results.
Nix has a whole host of hermetic build methods to prevent this from happening at all.
Check out Nix. It removes a lot of problems in builds.
It turns building from an unpredictable ritual to a mathematical, deterministic algorithm.
You shouldn’t be able to rerun the same build with different results
All it takes is a compiler embedding a timestamp somewhere in the output. You are aware that repeated builds is a pretty big effort right? In fact Fedora 41 has a change to make sure rpm builds are reproducible: https://fedoraproject.org/wiki/Releases/41/ChangeSet#Reproducible_Package_Builds
It is not the same build.
A variable (a timestamp) is being changed, so by definition it is not the same build.
You managed to agree with me without understanding the discussion.
Lets say you run a build that compiles v2.0 branch and store the artifacts as myproduct-2.0.2.tar.gz
You deploy that to your QA environment. Your testers have it and when they are done the results "looks good, time to release it to prod.
What you should do is take your build an promote it to released status. Now this can be picked up by customers or deployed to prod.
But, believe it not, there are people that branches named dev, test, prod. So when they complete testing on the artifacts above, they run another build on the prod branch and either release that to customers or deploy on internal prod.
You’re saying the same thing as me – when they do that prod build, its not the same artifacts as they tested in QA. In fact, anything you tested previously is no longer relevant because you have a new build.
Since you brought an OS package manager into the discussion (which wasn’t what I thought was being discussed), let’s look at from a fedora/rpm perspective. All I’m saying is that after building an rpm they push it through the pipeline. It goes to updates-testing and then later updates. The exact same rpm is promoted to updates from updates-testing. They do not build a new rpm for updates repo.
I see many people who have separate builds for each environment.
Nix is not an OS package manager by default.
It is a system for reproducible builds that can have many uses.
One example is NixOS, a system for reproducible system states.
Nix on its own is more like deterministic Make.
In Visual Studio you can set the build number in your project as something similar to a unix timestamp/raw excel date value, so you can convert it back to a date/time of the build.
In that case it would always increment on each build regardless of whatever version numbers you set.
