>... 1) First when will we have to switch? I know RetailSDK will be deprecated October 2022. ...
You would need to switch by the above date, so the sooner you will start getting familiar with the new GitHub based SDKs the better, the readme outlines details on how the Dev Experience look like in regards to the Commerce Scale Unit. Meantime, Dev VMs deploying via LCS are planned to not have any Retail components (like, for instance, RS, CPOS, HS, SampleStoreFront) pre-deployed there, that removal is planned to be completed sooner than Oct 2022. So, when those components are removed, and if you will still need to use the Legacy Retail SDK present on that Dev VM, you would need to deploy corresponding product (like RS, HS, CPOS) by leveraging on-prem Installers: Introduction to Commerce Sealed Installers either explicitly as outlined in that blog or, in case of On-Prem Scale Unit, via semi-automated way as shown in GitHub Scale Unit sample.
>... However it doesn't sound like everything is ready om Microsoft's end. ...
There are indeed activities still in progress on Microsoft side but at the same time we wanted to inform about the switch the sooner the better so the customers/partners are prepared well.
>... For example ISV packages and CloudPOS. ...
Can you outline specific details on what is missing in the new SDKs in regards to the above?
>... It sounds like when we switch over to CommerceSDK that we have to use GIT as the source control. Do I understand this correctly? ...
No, you don't have to change your internal Source Control. The fact the new Commerce SDK Samples live on GitHub simply means we now use more standard and open way of delivering samples than with the Legacy Retail SDK. The fact the Legacy Retail SDK gets updates only in a context of those LCS based DEV VMs is a restricting factor (for both - customers as well as Microsoft) - customers have to use that VM or copy the SDK/Samples from there to another machine in order to use it. With GitHub based samples we are employing industry standard way of delivering the SDK/Samples to the outside world. So if you don't want to use GitHub - you don't have to - you just would use GitHub to get the latest samples sources and then you could still use your existing source control to maintain those sources. I need to explicitly say that this GitHub approach let's us deliver the SDK/Sample changes to customers much faster and easier for the customers - you no longer need to update your entire LCS VM to get a new version of the SDK which could take hours, instead you just need to spend literally few minutes to sync to the latest on GitHub for the branch you need and this is it. This also allows us releasing SDK/Samples hotfixes much faster since we don't need to go through entire LCS pipeline - all the required SDK packages are available via public nuget feed.
Regarding Visual Studio vs VS Code, both can be used but with the latter more steps are automated, that is especially prominent in the above mentioned Scale Unit Installer, which employs lots of automation when is invoked via VS Code but that doesn't mean VS Code is the only way to develop it - you can still use Visual Studio or even directly command line commands.
>... However I do not see a project type on my .Net Framework project. ...
This is where the setting in the new Commerce SDK corresponding to the Scale Unit:
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
You can also see that via Visual Studio's project properties (right click the project and click Properties):
>... So we have to change them all to be Class Library (.Net Standard) projects? ...
Yes, that is especially important because the new, above mentioned Sealed Installers, deploy an ASP.NET Core 3.1 version of Retail Server and similar change will be available for Cloud deployed Retail Servers as well. This is the link which indicates the usages of netstandard while creating custom controllers.
>... do I need to change anything where this reference gets its package or not? ...
You don't need to, the packages.config is just another way to reference nuget packages especially since you are talking about Legacy Retail SDK.
>... I still don't understand the part that I need to get the packages from GIT. Is this for when I switch to CommerceSDK or is it something I need to do right now because I upgraded my Dev box to V10.0.22? ...
Packages are not actually retrieved from Git (I assume you meant GitHub), instead those above mentioned GitHub Samples are published on Git and those samples reference the new Commerce SDK nuget packages available via public feed. You only need to deal with them when working with the new SDK. To work with the Legacy Retail SDK keep using the same approach as you did before - retrieve everything from the LCS Dev VM.
>... Meaning that the RetailSDK that was saved to my Dev box under "K:\RetailSDK\Update" when I upgraded my Dev box in LCS to v10.0.22, doesn't have the DLLs for v10.0.22? ...
The fact you upgraded your LCS Dev VM means that VM got everything required for the Legacy Retail SDK/Samples to work, so if you updated it to specific 10.0.22 version - you have got everything on that VM required to create extensions by using Legacy Retail SDK.
>... If I have to get it from the GitHub repositories for v10.0.22, where do I save it to? Overwriting the RetailSDK\pkgs folder? ...
You don't need to mix packages from Retail and Commerce SDKs. Anyways, if you still want to see the location of the nuget packages as restored in the new GitHub based Commerce SDK, you can find them in the %UserProfile%/.nuget/packages
