Daedren 3 days ago Don't like this since it's just asking for code conflicts with any other developer's code and their own build number changes.I prefer setting the number on the CD pipeline. It's one less file to have changes in git.
cjk 16 hours ago I disagree that a timestamp is a “build number”. Additionally, injecting dates/times into builds is bad juju from a reproducibility perspective. Hamuko 16 hours ago Preferably you'd have a build server where you can use the build number. I use this to build my macOS application in GitHub Actions. [[ $GITHUB_REF_TYPE = "tag" ]] && MARKETING_VERSION=$GITHUB_REF_NAME || MARKETING_VERSION=$(git rev-parse --short HEAD) echo "Building $MARKETING_VERSION ($GITHUB_RUN_NUMBER)" agvtool new-version -all $GITHUB_RUN_NUMBER agvtool new-marketing-version $MARKETING_VERSION Non-tagged build gives me "Building a3d4743 (54)", tagged build gives me "Building 0.3.1 (55)". cjk 15 hours ago Agreed, CI-managed build numbers are a good way of handling this. I've done the same thing at my past handful of jobs.
Hamuko 16 hours ago Preferably you'd have a build server where you can use the build number. I use this to build my macOS application in GitHub Actions. [[ $GITHUB_REF_TYPE = "tag" ]] && MARKETING_VERSION=$GITHUB_REF_NAME || MARKETING_VERSION=$(git rev-parse --short HEAD) echo "Building $MARKETING_VERSION ($GITHUB_RUN_NUMBER)" agvtool new-version -all $GITHUB_RUN_NUMBER agvtool new-marketing-version $MARKETING_VERSION Non-tagged build gives me "Building a3d4743 (54)", tagged build gives me "Building 0.3.1 (55)". cjk 15 hours ago Agreed, CI-managed build numbers are a good way of handling this. I've done the same thing at my past handful of jobs.
cjk 15 hours ago Agreed, CI-managed build numbers are a good way of handling this. I've done the same thing at my past handful of jobs.
Don't like this since it's just asking for code conflicts with any other developer's code and their own build number changes.
I prefer setting the number on the CD pipeline. It's one less file to have changes in git.
I disagree that a timestamp is a “build number”. Additionally, injecting dates/times into builds is bad juju from a reproducibility perspective.
Preferably you'd have a build server where you can use the build number. I use this to build my macOS application in GitHub Actions.
Non-tagged build gives me "Building a3d4743 (54)", tagged build gives me "Building 0.3.1 (55)".Agreed, CI-managed build numbers are a good way of handling this. I've done the same thing at my past handful of jobs.