kennebel@lemmy.world
on 30 Jun 2024 19:08
nextcollapse
That is 100% up to every team to decide. Version numbering is completely arbitrary.
agressivelyPassive@feddit.de
on 30 Jun 2024 20:19
nextcollapse
I had lengthy discussions about that because two companies conventions collided.
We talked literally hours about the benefits of build numbers, branch specific identifiers and so on.
Kissaki@programming.dev
on 01 Jul 2024 09:31
collapse
What conclusion did you come to?
agressivelyPassive@feddit.de
on 01 Jul 2024 14:37
collapse
None. The project was ultimately cancelled for unrelated reasons.
DirigibleProtein@aussie.zone
on 30 Jun 2024 21:40
nextcollapse
Since version 3, TeX has used an idiosyncratic version numbering system, where updates have been indicated by adding an extra digit at the end of the decimal, so that the version number asymptotically approaches π. This is a reflection of the fact that TeX is now very stable, and only minor updates are anticipated. The current version of TeX is 3.141592653
magic_lobster_party@kbin.run
on 01 Jul 2024 08:29
collapse
Knuth has also decided that once he dies, a last version will be made which sets the version number exactly to pi.
Kissaki@programming.dev
on 01 Jul 2024 09:30
collapse
He’s gonna live a long life. Until we know pi.
magic_lobster_party@kbin.run
on 01 Jul 2024 11:10
collapse
He has to finish section 7.2.2 of his book
Cirk2@programming.dev
on 30 Jun 2024 22:00
collapse
I wish.
Sadly the google play store requires monotonically increasing build numbers, so any option of resetting build numbers after major releases goes out the window.
Do Google engineers get off on writing software that’s only compatible within their own little world, then offering it as some de facto standard?
Google Cloud had a ton of these that make it arbitrarily hard to use.
best_username_ever@sh.itjust.works
on 30 Jun 2024 19:15
nextcollapse
In regular “semantic versioning” (the most popular), there is no build number.
lysdexic@programming.dev
on 30 Jun 2024 19:27
nextcollapse
There are no hard set rules, and it depends on what uses you have for the build number.
Making it a monotonically increasing number helps with versioning because it’s trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It’s not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.
You sound like you’re focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.
superb@lemmy.blahaj.zone
on 30 Jun 2024 19:50
nextcollapse
It really depends on your needs. In most cases, I wouldn’t even bother.
I do have a project with a some software running on a microcontroller and a corresponding driver. I don’t record a build number, but I do record the timestamp when the build occurred. That way the driver can update the firmware if its timestamp is older than expected
key@lemmy.keychat.org
on 30 Jun 2024 19:58
nextcollapse
I’d usually do the former because by build number I usually mean pipeline or job id in a build server. You could build 4.0.4 and then 3.4.18 and so 4.0.4 could be build number 1026 while 3.4.18 is 1027.
You can also just use a special number to keep your version number unique when doing dev builds so your version number comes through like 3.5.2-48 and some might call the 48 a build number, in which case that would make sense to reset with each version number.
MajorHavoc@programming.dev
on 30 Jun 2024 20:34
nextcollapse
The approach I’ve seen most is using semantic versioning for releases, and having a continuously upward counting (not bothering to reset) build number for everything in between.
sxan@midwest.social
on 01 Jul 2024 01:25
nextcollapse
@best_username_ever mentioned Semantic Versioning. It’s an actual spec. Not everyone follows it, and it doesn’t make sense for a lot of things, and far too many people are dogmatic about it. But it’s a good thing to read, and it’s not long.
A related, but not tightly coupled, spec is Changelog. Used together, and used correctly these two are nice for users.
Kissaki@programming.dev
on 01 Jul 2024 09:28
collapse
Gives so much more meaning to version numbers. Immediately obvious how old, and from when.
Nobody knows when Firefox 97 released. If it were 22.2 you’d know it’s from February 2022.
It doesn’t conflict with semver either. You can use y.M.<release>. (I would prefer using yy.MM. but leading 0 is not semver.)
sxan@midwest.social
on 01 Jul 2024 11:50
nextcollapse
I’m with you; I prefer date versioning for many things. Semver does work really well for things with exposed APIs; it’s a stretch to justify using them with user tools, and especially GUI tools. Semver is used to great effect in Go - which is how it should be use: mainly by the language’s module management system. Outside of that, it’s human readable, but like XML, its main value is to machines, and only secondarily to humans.
Calendar versioning is far more human-oriented, and so more useful for things without exposed APIs or module tooling.
jjjalljs@ttrpg.network
on 01 Jul 2024 12:56
collapse
I really dislike calver for like libraries and apis. For something like Firefox it doesn’t matter as much. But for a library? I want to know if this version has breaking changes.
copygirl@lemmy.blahaj.zone
on 01 Jul 2024 04:08
collapse
Something else to consider in place of or in addition to a build number could also be using the git commit hash of what you’re building. Though I would only use that for non-stable releases.
For example, stable versions of Zig look like 0.12.1 and then there’s in-development releases like 0.13.0-dev.351+64ef45eb0. It uses semantic versioning where the “pre-release” is dev.351, which includes an incrementing build number, and the “build metadata” is 64ef45eb0, the commit hash it was built from. The latter allows a user to quickly look up the exact commit easily and thus know exactly what they’re using.
threaded - newest
.
That is 100% up to every team to decide. Version numbering is completely arbitrary.
I had lengthy discussions about that because two companies conventions collided.
We talked literally hours about the benefits of build numbers, branch specific identifiers and so on.
What conclusion did you come to?
None. The project was ultimately cancelled for unrelated reasons.
Knuth has also decided that once he dies, a last version will be made which sets the version number exactly to pi.
He’s gonna live a long life. Until we know pi.
He has to finish section 7.2.2 of his book
I wish. Sadly the google play store requires monotonically increasing build numbers, so any option of resetting build numbers after major releases goes out the window.
Do Google engineers get off on writing software that’s only compatible within their own little world, then offering it as some de facto standard?
Google Cloud had a ton of these that make it arbitrarily hard to use.
In regular “semantic versioning” (the most popular), there is no build number.
There are no hard set rules, and it depends on what uses you have for the build number.
Making it a monotonically increasing number helps with versioning because it’s trivial to figure out which version is newer. Nevertheless, you can also rely on semantic versioning for that. It’s not like all projects are like Windows 10 and half a dozen major versions are pinned at 10.0.
You sound like you’re focusing on the wrong problem. You first need to figure it what is your versioning strategy,and from there you need to figure out if a build number plays any role on it.
It really depends on your needs. In most cases, I wouldn’t even bother.
I do have a project with a some software running on a microcontroller and a corresponding driver. I don’t record a build number, but I do record the timestamp when the build occurred. That way the driver can update the firmware if its timestamp is older than expected
I’d usually do the former because by build number I usually mean pipeline or job id in a build server. You could build 4.0.4 and then 3.4.18 and so 4.0.4 could be build number 1026 while 3.4.18 is 1027.
You can also just use a special number to keep your version number unique when doing dev builds so your version number comes through like 3.5.2-48 and some might call the 48 a build number, in which case that would make sense to reset with each version number.
The approach I’ve seen most is using semantic versioning for releases, and having a continuously upward counting (not bothering to reset) build number for everything in between.
@best_username_ever mentioned Semantic Versioning. It’s an actual spec. Not everyone follows it, and it doesn’t make sense for a lot of things, and far too many people are dogmatic about it. But it’s a good thing to read, and it’s not long.
A related, but not tightly coupled, spec is Changelog. Used together, and used correctly these two are nice for users.
I really like Calendar Versioning CalVer.
Gives so much more meaning to version numbers. Immediately obvious how old, and from when.
Nobody knows when Firefox 97 released. If it were
22.2
you’d know it’s from February 2022.It doesn’t conflict with semver either. You can use
y.M.<release>
. (I would prefer usingyy.MM.
but leading 0 is not semver.)I’m with you; I prefer date versioning for many things. Semver does work really well for things with exposed APIs; it’s a stretch to justify using them with user tools, and especially GUI tools. Semver is used to great effect in Go - which is how it should be use: mainly by the language’s module management system. Outside of that, it’s human readable, but like XML, its main value is to machines, and only secondarily to humans.
Calendar versioning is far more human-oriented, and so more useful for things without exposed APIs or module tooling.
I really dislike calver for like libraries and apis. For something like Firefox it doesn’t matter as much. But for a library? I want to know if this version has breaking changes.
Something else to consider in place of or in addition to a build number could also be using the git commit hash of what you’re building. Though I would only use that for non-stable releases.
For example, stable versions of Zig look like
0.12.1
and then there’s in-development releases like0.13.0-dev.351+64ef45eb0
. It uses semantic versioning where the “pre-release” isdev.351
, which includes an incrementing build number, and the “build metadata” is64ef45eb0
, the commit hash it was built from. The latter allows a user to quickly look up the exact commit easily and thus know exactly what they’re using.