forked from bvibber/emsdk-npm
-
Notifications
You must be signed in to change notification settings - Fork 5
Open
Description
To follow this versioning scheme, make the NPM releases consistent with EMSDK. (This concerns emsdk-npm only).
- Implement this by git branching for each EMSDK version. Branches are named
v2.0.11,v2.0.10, etc. In each branch, store adefault_version.jsfile that contains the EMSDK version string. This file sets the release to download for the rest of the package. Don't make the version string modifiable by the user.package.jsonis also edited to reflect the version. - Install EMSDK on npm install step when version is hardcoded
- Make a CI runner to:
- Merge
mainchanges to each version branch - Publish updated version branches
- Merge
- Make a CI runner to:
- Check for new EMSDK versions
- Prepare a new version branch
- Test the new version branch
- Publish to NPM
- Tag
latestonly for the latest possible SDK version (don't publishlatesttag for older versions)
- Investigate whether NPM recognizes
+buildversion syntax and ranges them correctly. The+buildpart will track eachmaincode merge. (e.g.v2.0.11+1609425262represents themainrevision dated 12/31/2020 that serves EMSDK 2.0.11)+buildinformation is skipped persemverspec, see StackOverflow and NPM. This has induced the "workaround" convention of using-prereleaseinfo to denote precedence (see: vscode).Resolution: UseUsev2.0.11-1609425262version formatv2.0.11-0format- Practical example:
- https://www.npmjs.com/package/flex-sdk
- https://gist.github.com/JamesMGreene/9916485
- Install string will likely be
npm install -D emscripten-sdk ~2.0.11-0
- Track separate NPM packages for the following scenarios:
-
emscripten-sdk: Versioned packages in llvm backend, e.g.,emscripten-sdk@2.0.11,emscripten-sdk@2.0.10, etc. -
emscripten-sdk-npm: Generic package for full control: e.g., requestinglatest,fastcomp,tot
-
Versioning syntax
Metadata
Metadata
Assignees
Labels
No labels