Daedren 4 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. msephton 4 hours ago They are fair points. But it's only me working on it (indie dev) and there is no CD pipeline, just Cmd+R :)
msephton 4 hours ago They are fair points. But it's only me working on it (indie dev) and there is no CD pipeline, just Cmd+R :)
cjk 2 days ago I disagree that a timestamp is a “build number”. Additionally, injecting dates/times into builds is bad juju from a reproducibility perspective. Hamuko 2 days 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 2 days 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 2 days 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 2 days 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 2 days 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.
They are fair points. But it's only me working on it (indie dev) and there is no CD pipeline, just Cmd+R :)
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.