Update version to 1.0.1

[Eskibear]

requires #83

Mainly to ship a fix for #81, unblocking customers from using this lib in some Browser related environments.

[avanigupta]

Should this PR go to main branch first, and then main can be merged to release? We normally dont merge code changes directly to release branch.

[Eskibear]

@avanigupta current branching model is: changes go into main branch, and are merged to release branch. Only PRs related to official version bumping go directly into release branch. And for each release we do tagging. Benefit is the two branches are almost consistent (even though not strictly), and for local/dev build, they don’t use the same official version by default. The disadvantage is like here, occasionally there would be conflicts requiring manual resolving.

Your suggestion also makes sense, making the branches strictly consistent. I.e from what I understand,

• main: default branch where most changes go into. And we bump stable version here as well.
• release/stable/*: based on main, used for releasing.
• preview: if necessarily to maintain two major version at the same time, based on main but ahead of main with preview changes.
• release/preview/*: based on preview, for releasing preview versions.

i'm ok to switch to what you mentioned. A slight disadvantage is: in main and preview branch, if any developer checks out code, makes some changes, and build a local package to dev/test, it sends telemetry with an official version but the code is unpredicted. might affect statistics somethimes, but not a big problem though.

[avanigupta]

build a local package to dev/test, it sends telemetry with an official version

Is there a way to identify local environment and change the version? In .NET, we can identify this and change the version accordingly (link)

What is the release branch strategy followed by JS SDK team?

[Eskibear]

Is there a way to identify local environment and change the version?

Basically the version is determined by version in package.json. Of course in practice we have multiple ways to distinguish dev/prod env.

E.g. we can add more build scripts:

• npm run build:dev updates the version in package.json first before building package.
• npm run build:prod directly builds the package.

The problem is we cannot build a package with local version without changing the package.json file simply using npm built-in functionality. That leads to inconvenience when we want to check in code, because pacakge.json is dirty with unwanted version change. You have to be careful not to include them. That's why I don't like the solution and want to leave packageJSON.version unchanged during building.

BTW, a custom build script can do anything. Technically we are not blocked. The packageJSON.version problem I mentioned above can also be solved by a custom build script, though not that elegant. I.e. when build:dev, we can modify the version, do the build, and restore the version. The version in CorrelationHeader is determined by version.ts, which should be identical to packageJSON.version. With separate scripts to build dev/prod packages, it's feasible to update the file as well. This is not a problem.

[Eskibear]

What is the release branch strategy followed by JS SDK team?

JS SDK repo simply has one protected branch main. They create PR against the main branch, and do releasing with main branch, and add proper tagging to specific commit. The SDK repo include multiple projects owned by different teams, probably not the one we want to follow.

[Eskibear]

@avanigupta Later I can proceed to switch the branching model, as I mentioned above. Aligning with our other repos is also important and requires less additional context information, making it easier to maintain.

The steps would be:

• merge release back into main, with a merge commit. So the two branches would be "even"
• create a PR to update dev-build scripts, which can build local dev version without eventually changing package.json.