[Identity] Prepare v1 release without persistent cache feature #14909
Assignees
Labels
Azure.Identity
blocking-release
Blocks release
Client
This issue points to a problem in the data-plane of the library.
Milestone
Comments
ghost
added
the
needs-triage
ramya-rao-a
added
Azure.Identity
Client
ghost
removed
the
needs-triage
ghost
pushed a commit
that referenced
this issue
Apr 17, 2021
…ntial to v1 only for browsers, and fixing Karma browser bundles (#14910) This PR makes it so `ClientSecretCredential` behaves like how it did on v1 only for browsers. It also ensures browser bundles can be used when built with Karma. --- ## ClientSecretCredential (and also UsernamePasswordCredential) Since the inception of Identity, we've been relying on `ClientSecretCredential` to be available in browsers to make it easier for us to automate bowser tests. Whether `ClientSecretCredential` should continue being available on browsers in the future, is something yet to be decided. We started a conversation on the matter here: #14879 Our current plan is to switch master back to v1, as you can see here: #14909 Since the v2 changes to `ClientSecretCredential` won't be reverted, that means that as soon as we move master back to v1, all of our current clients will immediately start working with the latest `ClientSecretCredential`. `ClientSecretCredential` was rewritten to use MSAL, specifically `@azure/msal-node`, which is not intended to work on browsers. This PR makes it so `ClientSecretCredential` is kept as it was on v1 only for browsers. This will: - Allow us to keep our current browser recordings. - Allow us to continue using this credential for browser tests. - On v1, dropping this credential on browsers would be a breaking change, so this technically reduces the differences with v1. **Important:** Keep in mind that while we've always supported this credential in browsers, it can only work if browser security is disabled. This isn't recommended outside of our tests, and it's not something we should be advertising. (Later we also did the same to `UsernamePasswordCredential`). --- ## Browser bundles While my initial change was scoped to one credential, I asked Harsha to test this PR and he found that the browser bundles would not work with Identity v2. We decided to fix it right away since this PR wouldn't be very useful with broken browser bundles.
|
After thinking this better, I'll do the v2 branch before reverting changes. I need to remove the persistence layer from v1, which then we would need to add to the v2 branch, since we already shipped a v2 branch with it. Seems cleaner to keep v2 branch as is and start dropping changes on master. |
|
Feature branch for Identity 2.0.0-beta.3: tree/identity-2.0.0-beta.3. |
jay-most
pushed a commit
to jay-most/azure-sdk-for-js
that referenced
this issue
Apr 26, 2021
…ntial to v1 only for browsers, and fixing Karma browser bundles (Azure#14910) This PR makes it so `ClientSecretCredential` behaves like how it did on v1 only for browsers. It also ensures browser bundles can be used when built with Karma. --- ## ClientSecretCredential (and also UsernamePasswordCredential) Since the inception of Identity, we've been relying on `ClientSecretCredential` to be available in browsers to make it easier for us to automate bowser tests. Whether `ClientSecretCredential` should continue being available on browsers in the future, is something yet to be decided. We started a conversation on the matter here: Azure#14879 Our current plan is to switch master back to v1, as you can see here: Azure#14909 Since the v2 changes to `ClientSecretCredential` won't be reverted, that means that as soon as we move master back to v1, all of our current clients will immediately start working with the latest `ClientSecretCredential`. `ClientSecretCredential` was rewritten to use MSAL, specifically `@azure/msal-node`, which is not intended to work on browsers. This PR makes it so `ClientSecretCredential` is kept as it was on v1 only for browsers. This will: - Allow us to keep our current browser recordings. - Allow us to continue using this credential for browser tests. - On v1, dropping this credential on browsers would be a breaking change, so this technically reduces the differences with v1. **Important:** Keep in mind that while we've always supported this credential in browsers, it can only work if browser security is disabled. This isn't recommended outside of our tests, and it's not something we should be advertising. (Later we also did the same to `UsernamePasswordCredential`). --- ## Browser bundles While my initial change was scoped to one credential, I asked Harsha to test this PR and he found that the browser bundles would not work with Identity v2. We decided to fix it right away since this PR wouldn't be very useful with broken browser bundles.
|
Turns out the most of the other features are not as useful to the end user in the absence of the persistent cache feature
Therefore, we will not be shipping a v1 update as stated in this issue. |
maorleger
added a commit
that referenced
this issue
May 4, 2021
## What Reverting d79b277 since we are now no longer pinning to 1.3.0. But we still have multiple Identity versions in-flight, so we need the common-versions config ## Why This will resolve https://dev.azure.com/azure-sdk/internal/_build/results?buildId=873579&view=results As per #14909 (comment) we no longer need to prep a v1 update to identity so we can standardize on ^1.1.0 (as there will be no changes in v1 that will force re-recording)
deyaaeldeen
pushed a commit
to deyaaeldeen/azure-sdk-for-js
that referenced
this issue
May 4, 2021
## What Reverting d79b277 since we are now no longer pinning to 1.3.0. But we still have multiple Identity versions in-flight, so we need the common-versions config ## Why This will resolve https://dev.azure.com/azure-sdk/internal/_build/results?buildId=873579&view=results As per Azure#14909 (comment) we no longer need to prep a v1 update to identity so we can standardize on ^1.1.0 (as there will be no changes in v1 that will force re-recording)
openapi-sdkautomation bot
pushed a commit
to AzureSDKAutomation/azure-sdk-for-js
that referenced
this issue
Jun 28, 2021
[DataBox] Bump the api version to add new values for enums for JobStageStatus (Azure#14909) * copy of 2021-03-01, first commit * adding new api version and its example * updating readme files with 2021-05-01 version and cSpell.json too with Tera as acceptable word * updating 2021-readme files * adding reference to the file * removing track1 changes for python
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
At this point, we have shipped versions 2.0.0-beta.1 and 2.0.0-beta.2 with multiple new features and a few breaking changes. One of the features is the new persistent cache feature which depends on
@azure/msal-node-extensionswhich pulls in native dependencies. While we work on solutions to improve the experience here (See #14346, #14295, #14346), we want to take the rest of the features in the master branch GA. We will be reverting the breaking changes and shipping a v1 to save the major version update for a later date when we have solutions for the native dependencies problem.Below is the plan:
We will ship both v1.4.0 and v2.0.0-beta.3 in the May milestone
Will target June release to ship persistent cache feature. This will be the v2 GA (or v1 if we figure out to do everything without any breaking changes)
cc @sadasant, @witemple-msft, @maorleger, @schaabs, @joshfree
The text was updated successfully, but these errors were encountered: