1 | # heroku-version-infer
|
2 |
|
3 | infers app versions for automatic heroku deploys
|
4 |
|
5 | ```sh
|
6 | npm install --save @quarterto/heroku-version-infer
|
7 | ```
|
8 |
|
9 | ```json
|
10 | {
|
11 | "name": "my-awesome-heroku-app",
|
12 | "version": "0.0.0-development",
|
13 | "scripts": {
|
14 | "postinstall": "heroku-version-infer"
|
15 | }
|
16 | }
|
17 | ```
|
18 |
|
19 | ## why
|
20 |
|
21 | because you want to tag versions for things like error reporting, QA, Tim writing on whiteboards, but you don't want to manually tag things. heroku-version-infer comes up with an arbitrary monotonically increasing version number automatically, so you don't have to.
|
22 |
|
23 | ## how
|
24 |
|
25 | the version number is the number of merge commits into the history of the deployed commit. if you have Github branch protection, there will be no code changes on `master` without an associated merge, so a particular version will always contain the same code. this number will increase if *and only if* there are code changes, which is exactly what we need from a version number.
|
26 |
|
27 | this assumption breaks down with Heroku review apps, where multiple concurrent branches with the same number of merges may be deployed at the same time. to disambiguate in this case, the first 7 characters of the commit hash are appended to the version.
|
28 |
|
29 | the inferred version is written to the `version` field in `package.json`. you're probably already used to writing `require('../package.json').version`.
|
30 |
|
31 | ## licence
|
32 |
|
33 | mit
|