pnp
Enhancement: `teams cache remove` should work with new teams client
Currently the command teams cache remove doesn't work with the new Teams client. Let's change the command to support the new teams client as well.
All info can be found here: https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/teams-administration/clear-teams-cache
Let's add a new option so we support both the new and classic Teams client:
| Option | Description |
|---|---|
-c, --client [client] |
Teams client to target. Possible values are: new, classic. Default value is new. |
Do you have some more information about what's not working and what to change?
The current command doesn't do anything regarding the new Teams client. The cache files are stored in a different location. All info can be found here: https://learn.microsoft.com/en-us/microsoftteams/troubleshoot/teams-administration/clear-teams-cache
I'm wondering if maybe we should add a switch --classicClient or something like that so we still support clearing the cache of the classic client?
I'm wondering if maybe we should add a switch
--classicClientor something like that so we still support clearing the cache of the classic client?
I suggest we use --client new (default)|classic just so that we have room to accommodate more changes in the future if need be.
Looks good! Just realized, that if we use new as the default, it's a breaking change. So until v8 we should use classic as default to stay backwards compatible and with v8 we can switch to new as the new default. Other that that, it's good to go 🚀
Do we really consider this command to be a scripting command? I would assume it's just something like an spfx command. When a new version of SPFx is released, we update the commands to work with the newest version.
Do we really consider this command to be a scripting command? I would assume it's just something like an
spfxcommand. When a new version of SPFx is released, we update the commands to work with the newest version.
It's not about scripts: it's about the expectations. The SPFx project upgrade command, when not provided any arguments, upgrades the project to the latest SPFx version that we support. That expectation doesn't change when we introduce new versions, only the target version moves. If you want to upgrade to a specific version, you can provide its version explicitly. Here we'd be changing how the command works, so if you used it in the past to clear the cache for the classic client, and you upgrade the CLI, it no longer works for you, without changing how you invoke it. This is why I'm considering it a breaking change.
In my opinion, this is quite identical to teams cache remove, people just expect it to work with the latest Teams client isn't it? Also, the classic Teams client will be marked end of support on July 1. It would look odd to me that if you don't provide any option, we, by default target the client that isn't supported anymore.
In my opinion, this is quite identical to
teams cache remove, people just expect it to work with the latest Teams client isn't it? Also, the classic Teams client will be markedend of supporton July 1. It would look odd to me that if you don't provide any option, we, by default target the client that isn't supported anymore.
This is tricky. Your reasoning is based on an assumption that everyone is already on the new Teams client, which I don't think is the case. Many organizations run software that's out of support because the cost of upgrade is non trivial to them. I stand by my opinion that changing which client we target by default is a breaking change. The few months between July and September/October, when our next major version will likely land, isn't that big of an issue I think, and it allows us to abide by our contract of not changing functionality in non-backwards compatible way in non-major releases.
This is tricky. Your reasoning is based on an assumption that everyone is already on the new Teams client, which I don't think is the case.
I don't assume this at all to be clear. There are still a few people left who are using the classic Teams client for sure. But the large majority of people are using the new client.
In fact, when I look at the figure below, even people that force the classic client on their tenant, will be pushed to the new client over 1 week.
So that will make the amount of people that are still using the classic Teams even smaller.
Many organizations run software that's out of support because the cost of upgrade is non trivial to them.
I know if there are breaking changes for Teams apps. As far as I can tell, all Teams apps will work just fine, no?
The few months between July and September/October, when our next major version will likely land, isn't that big of an issue I think, and it allows us to abide by our contract of not changing functionality in non-backwards compatible way in non-major releases.
Not deploying breaking changes is super important indeed, totally agree with that. However, just like I mentioned earlier, we have a few exceptions here, e.g. nearly all spfx commands, that are just not meant for scripting. People just expect that all spfx commands will work with the latest version. And to be honest, I'm pretty sure if we organize a poll in public and ask "Which Teams client should be targeted by teams cache remove?", the new Teams client will emerge as the declared winner.
From what I am aware the migrate between classic teams and new is rather seamless as it's just the client. All teams and apps remain. Am I missing something here?
I think the similarity with this command to spfx upgrade is good one. When a new SPFx version is released we just update those commands so that they default to the newer version and we don't consider this breaking change. We still support previous versions, just the default change.
In the other hand what @waldekmastykarz mentioned that it's only a few months between the change and next major so if this command is not that much used I guess it's not a big deal.
So to sum up: I would change it so that the default would be new teams client. But if the command telemetry show that it is not that much used I guess it's totally fine if we wait a few months.
Tbh, this is quite tricky. I understand both cases, in which this would appear as a breaking change, and on the other hand that everyone is being forced to the new version anyway. Personally, I'm weighing more towards using new as default. The main reason is that I already had several clients complaining about the new experience, as people always tend to do 😄
Given the timeline @milanholemans provided, people are already shifting to the new experience, so we should update this command to align with the timeline. We can update the remarks in our docs, making it clear that the command now supports the new client as default. However, you can still clear the classic cache using --client classic.
To be safe, shall we include this into the next major? We already have a branch for it so we can start working on it.
All good for me, then I would also assume we will go with new as default.