6 ms·

I'm using similar versioning for pre-build packages, but it's extended with commit information to 1:1 mapping to the source tree: local date=$(git log -1 --f

I'm using similar versioning for pre-build packages, but it's extended with commit information to 1:1 mapping to the source tree: local date=$(git log -1 --format="%cd" --date=short | sed s/-//g) local count=$(git rev-list --count HEAD) local commit=$(git rev-parse --short HEAD) echo "$date.${count}_$commit" Example result: 20191121.68_84f90ff It provides user about general information about when program was updated along with specific information for developer for bug reporting. Also, it allows intraday releases.

vegardx 7y ago
You can also just use "git describe" to get more or less the exact same information, which is useful for development releases that are untagged when using versioning schemes like semantic versioning.
edejong 7y ago
It helps to have the versioning ordered correctly, so I'd zero-pad the ${count} variable, like so: printf "%s.%03d_%s\n" $date $count $commit
boris 7y ago
In build2 we do something similar for snapshot versioning between releases by incorporating the date and commit id into the pre-release component of semver. The result is a unique, properly ordered version for every commit in a project (we call it "continuous versioning"). If anyone is interested, here are the details: https://build2.org/build2/doc/build2-build-system-manual.xhtml#module-version https://build2.org/build2/doc/build2-build-system-manual.xht...
emptysea 7y ago
FYI, using `local foo=$(some-command)` does not actually make the variable local. main() { local count=$(git rev-list --count HEAD) echo $count foo } foo() { echo $count } main prints: 2282 2282
- minitech 7y ago
  Sure it does, that’s just how locals work (in bash and similar). Try printing it after `main` with and then without `local`.
  - emptysea 7y ago
    Ah my mistake Anyways there are some more subtle caveats discussed in this blogpost I was trying to remember: https://jmmv.dev/2018/03/shell-readability-local.html https://jmmv.dev/2018/03/shell-readability-local.html
JoshTriplett 7y ago
For several packages I maintain, the version number is just $(git rev-list --count HEAD). One monotonically increasing number, nothing else. (This is for software that does not do updates to old releases. If you do updates to old releases, you need an additional version number component for that.)

vegardx 7y ago

You can also just use "git describe" to get more or less the exact same information, which is useful for development releases that are untagged when using versioning schemes like semantic versioning.

edejong 7y ago

It helps to have the versioning ordered correctly, so I'd zero-pad the ${count} variable, like so: printf "%s.%03d_%s\n" $date $count $commit

boris 7y ago

In build2 we do something similar for snapshot versioning between releases by incorporating the date and commit id into the pre-release component of semver. The result is a unique, properly ordered version for every commit in a project (we call it "continuous versioning"). If anyone is interested, here are the details: https://build2.org/build2/doc/build2-build-system-manual.xhtml#module-version https://build2.org/build2/doc/build2-build-system-manual.xht...

emptysea 7y ago

FYI, using `local foo=$(some-command)` does not actually make the variable local. main() { local count=$(git rev-list --count HEAD) echo $count foo } foo() { echo $count } main prints: 2282 2282

minitech 7y ago
Sure it does, that’s just how locals work (in bash and similar). Try printing it after `main` with and then without `local`.
- emptysea 7y ago
  Ah my mistake Anyways there are some more subtle caveats discussed in this blogpost I was trying to remember: https://jmmv.dev/2018/03/shell-readability-local.html https://jmmv.dev/2018/03/shell-readability-local.html

JoshTriplett 7y ago

For several packages I maintain, the version number is just $(git rev-list --count HEAD). One monotonically increasing number, nothing else. (This is for software that does not do updates to old releases. If you do updates to old releases, you need an additional version number component for that.)