## Summary
We need to implement a simple versioning schema for hermes-windows releases from release branches and
pre-releases from the main branch.
Thanks a lot to @dannyvv who implemented the version generation for this PR.
## The versioning schema
The versioning schema is described in the new `doc\WindowsVersioning.md ` document:
- The **pre-release package versions** built in the `main` branch look like
**0.0.0-2209.9002-8af7870c** where the `<major>.<minor>.<patch>` versions are
always `'0.0.0'`, and the prerelease part that follows after `'-'` is
`'yyMM.drrr-hhhhhhhh'`. Where `'yy'` are two numbers for the year, `'MM'` are
two numbers for the month, `'d'` is the day without `0` prefix, `'rrr'` is a
three digit number for the today's revision, and `'hhhhhhhh'` are the first 8
hexadecimal numbers from the source GitHub commit hash.
- The **pre-release file versions** look like `0.0.2209.9002` where the the
encoding is `'0.0.yyMM.drrr'`. Where numbers after `'0.0.'` have the same
encoding as for the pre-release package version.
- The **released package versions** use the usual semantic schema which is
based on RNW release numbers like `0.70.1`, where the `'0.70'` is the
`<major>.<minor>` release of RNW and RN, and the last number is a `'patch'`
number for that release. Note that the `'patch'` number will not match the
`'patch'` number of the RNW. We are going to generate the `'patch'` number
using ADO build revision with format `'r'` that avoids `0` prefixes for the
version to be valid semantic version.
- The `release file versions` look like `0.70.1.0` to match the version of the package. The last part of the file version number is always `0`.
Note, that the release version is going to be generated by the release pipeline.
We do not expect the release version to be set somewhere in the source files or by using the processes like beachball.
## Implementation details
- The `publish.yml` has a new `Setup` job that generates version numbers for the package and files using the new `setVersionNumber.js` script. The result of this job is used by `jobs.yml` to create two new variables `semanticVersion` and `fileVersion`. One is used for package semantic version and the other for the DLL/EXE file versions.
- The `semanticVersion` and `fileVersion` are passed to `cibuild.ps1` where they are used to update CMake project version and `package.json` version. The `fileVersion` is passed to CMake build as `HERMES_FILE_VERSION` definition.
- We ensure that `hermes.dll`, `inspector.dll`, and `hermes.exe` projects have the `version.rc` generated with the product and file versions, and with other meta-data settings.
- The generated Nuget packages pickup their versions from the `package.json` file.
- We set back versions in `package.json` and `CMakeLists.txt` to `0.12.0` to match `facebook/hermes` repo. This is done to reduce the diff between the two repos. We are always going to generate these versions in our release pipeline.
- The `ReactNative.Hermes.Windows.Fat.nuspec` is updated to match the `ReactNative.Hermes.Windows.nuspec` because it was missing some files such as `License`, and also had some unnecessary files such as `ninja` build scripts. Now the only extra files there are the symbol `*.pdb` files.
16062c0cd1