4 ms·

A sequential build/release number would suffice in many cases. If the thing you're shipping isn't meant to be a dependency for other projects, then semantic ve

A sequential build/release number would suffice in many cases. If the thing you're shipping isn't meant to be a dependency for other projects, then semantic versioning doesn't really fit. In trunkver though, using the timestamp of the build time is a little weird, since you could inadvertently end up building an earlier version of trunk at a later time. Putting an identifier of the job that built the release in the version number also seems heavy for what could just be an entry in a log file for when you need those forensics.

PaulKeeble 2y ago
What happens with build number is you end up going back to the CI system and looking up what change it actually built and when it happened. I can see the advantage of having all 3 in the build name, I have done similar in the past for continuously released server software where there is no need for versioning numbers although typically I too have shortened it to just the build number because we have the CI system to go into if we need to.
status_quo69 2y ago
Generally agree with your points about how semver isn't really necessary. I suppose the benefit here would be that dep management tools like dependabot could automatically raise pull requests when a new version is released, which would be pretty cool. If only my peer engineers actually paid attention to dependency updates. As an aside, instead of an auto incrementing build number I'd suggest the git sha since it's: 1. Already there and points to a specific version of the code in the repo 2. Globally unique 3. Can assist with reproducible builds (i.e. 6afed54 was acting weird, let's build it locally and take a look) 4. Gives you an easy diff target to dump "release notes". Just diff to the previous and dump the merge commit messages.
guytv 2y ago
The problem with sequential build/release number is that you have to keep it in git (so you could increment), which results in a number of complications and annoyances.
jillesvangurp 2y ago
Time is sequential. Otherwise, sequential build numbers are kind of hard to orchestrate in a distributed architecture. Not impossible. But it introduces complexities if you have many build machines. I don't think semver compatibility is that relevant/meaningful here. Normally I'd also want the branch name as part of the version tag. We do that with our docker containers. Adding the timestamp at the beginning is a good idea as it helps sort things by recency. I might copy that. The CI build id is nice, but I typically don't archive these anyway. All this concatenated gets a bit long.
- rswail 2y ago
  git describe gives you what you want. It gives you the nearest tag, the number of commits from that tag and the git commit ID.
  - jillesvangurp 2y ago
    We don't use git tags for ordinary deploys. Every push to production gets deployed. And a timestamp is useful for sorting lists of container images.
- hifromwork 2y ago
  >Time is sequential. Otherwise, sequential build numbers are kind of hard to orchestrate in a distributed architecture Time is sequential, but this means that just building an older version is now a production breaking incident. That's weird to me, but I'm not a CD person.

PaulKeeble 2y ago

What happens with build number is you end up going back to the CI system and looking up what change it actually built and when it happened. I can see the advantage of having all 3 in the build name, I have done similar in the past for continuously released server software where there is no need for versioning numbers although typically I too have shortened it to just the build number because we have the CI system to go into if we need to.

status_quo69 2y ago

Generally agree with your points about how semver isn't really necessary. I suppose the benefit here would be that dep management tools like dependabot could automatically raise pull requests when a new version is released, which would be pretty cool. If only my peer engineers actually paid attention to dependency updates. As an aside, instead of an auto incrementing build number I'd suggest the git sha since it's: 1. Already there and points to a specific version of the code in the repo 2. Globally unique 3. Can assist with reproducible builds (i.e. 6afed54 was acting weird, let's build it locally and take a look) 4. Gives you an easy diff target to dump "release notes". Just diff to the previous and dump the merge commit messages.

guytv 2y ago

The problem with sequential build/release number is that you have to keep it in git (so you could increment), which results in a number of complications and annoyances.

jillesvangurp 2y ago

Time is sequential. Otherwise, sequential build numbers are kind of hard to orchestrate in a distributed architecture. Not impossible. But it introduces complexities if you have many build machines. I don't think semver compatibility is that relevant/meaningful here. Normally I'd also want the branch name as part of the version tag. We do that with our docker containers. Adding the timestamp at the beginning is a good idea as it helps sort things by recency. I might copy that. The CI build id is nice, but I typically don't archive these anyway. All this concatenated gets a bit long.

rswail 2y ago
git describe gives you what you want. It gives you the nearest tag, the number of commits from that tag and the git commit ID.
- jillesvangurp 2y ago
  We don't use git tags for ordinary deploys. Every push to production gets deployed. And a timestamp is useful for sorting lists of container images.
hifromwork 2y ago
>Time is sequential. Otherwise, sequential build numbers are kind of hard to orchestrate in a distributed architecture Time is sequential, but this means that just building an older version is now a production breaking incident. That's weird to me, but I'm not a CD person.