|
| 1 | +# How to release the ecs-logging-nodejs packages in this repo |
| 2 | + |
| 3 | +There are two types of packages in this repo: |
| 4 | + |
| 5 | +1. The `@elastic/ecs-helpers` utility package that is used by the others, and |
| 6 | +2. the `@elastic/ecs-[...]-format` packages for supported logging frameworks |
| 7 | + that are meant to be used by end users. |
| 8 | + |
| 9 | +The ecs-helpers utility is versioned, released, and tagged independently from |
| 10 | +the others. |
| 11 | + |
| 12 | +## Releasing `@elastic/ecs-helpers` |
| 13 | + |
| 14 | +Assuming "x.y.z" is the release version: |
| 15 | + |
| 16 | +1. Choose the appropriate version number according to semver. |
| 17 | +2. Create a PR that: |
| 18 | + - bumps the "version" in "packages/ecs-helpers/package.json", |
| 19 | + - updates "packages/ecs-helpers/CHANGELOG.md", if necessary, and |
| 20 | + - is named something like "release @elastic/ecs-helpers@x.y.z", if the PR |
| 21 | + is only about doing the release. (If this PR is also related to other |
| 22 | + changes, then the commit/PR title should include mention of those |
| 23 | + things as well.) |
| 24 | +3. Get the PR approved and merged. |
| 25 | +4. Tag the commit as follows, in a git clone with the merged commit: |
| 26 | + ``` |
| 27 | + git tag ecs-helpers-vx.y.z |
| 28 | + git push origin ecs-helpers-vx.y.z |
| 29 | + ``` |
| 30 | +5. Publish to npm, in a clean git clone: |
| 31 | + ``` |
| 32 | + git status # this should show "working tree clean" |
| 33 | + cd packages/ecs-helpers |
| 34 | + npm publish |
| 35 | + ``` |
| 36 | +
|
| 37 | +## Releasing `@elastic/ecs-[...]-format` |
| 38 | +
|
| 39 | +1. Choose the appropriate version number. All `ecs-*-format` packages currently |
| 40 | + coordinate their versions. That means that if "1.2.3" is the current latest |
| 41 | + release of any those packages, then the next release version of any of |
| 42 | + them is after that. Use `git tag -l` to list current versions. |
| 43 | +
|
| 44 | + For example, if the latest versions are [email protected] and |
| 45 | + [email protected], and a new release only for ecs-morgan-format |
| 46 | + is being done, then the next version should be: |
| 47 | + - `1.2.4` for a patch-level release, |
| 48 | + - `1.3.0` for a minor-level release, or |
| 49 | + - `2.0.0` for a major-level release |
| 50 | +
|
| 51 | + This is a bit weird for some cases, but allows use to have a simple `vx.y.z` |
| 52 | + tag for referring to the source code for any published release. |
| 53 | +
|
| 54 | +2. Create a PR that: |
| 55 | + - bumps the "version" in "packages/ecs-[...]-format/package.json", |
| 56 | + - updates "packages/ecs-[...]-format/CHANGELOG.md", if necessary, and |
| 57 | + - is named something like "release vx.y.z" if all format packages are |
| 58 | + being released or "release @elastic/[email protected]" if just |
| 59 | + one of them is being released. |
| 60 | + (If this PR is also related to other changes, then the commit/PR title |
| 61 | + should include mention of those things as well.) |
| 62 | +
|
| 63 | +3. Get the PR approved and merged. |
| 64 | +
|
| 65 | +4. Tag the commit as follows, in a git clone with the merged commit: |
| 66 | + ``` |
| 67 | + git tag vx.y.z |
| 68 | + git push origin vx.y.z |
| 69 | + ``` |
| 70 | +
|
| 71 | +5. Publish to npm, in a clean git clone: |
| 72 | + ``` |
| 73 | + git status # this should show "working tree clean" |
| 74 | +
|
| 75 | + # for each of the packages being released: |
| 76 | + cd packages/ecs-...-format |
| 77 | + npm publish |
| 78 | + ``` |
| 79 | +
|
0 commit comments