SCRT-HQ
📣 PSGSuite 3.0.0 Incoming! Release and breaking change details inside 👀 🎉
PSGSuite 3.0.0 Release & Breaking Change Details
TL;DR
If you are using PSGSuite with PowerShell 7.4 or greater, there should be no expected breaking changes with the PSGSuite 3.0.0 release.
If you are required to use PSGSuite with a PowerShell version LOWER than 7.4 such as Windows PowerShell, make sure your Install-Module and Import-Module calls are referencing a MaximumVersion of at least 2.37.0, but no greater than 2.99.99:
Install-Module PSGSuite -MaximumVersion 2.99.99
# OR
Import-Module PSGSuite -MaximumVersion 2.99.99
Background
It has been just under 5 years since the last PSGSuite release, with the latest 2.x release garnishing 94,694 downloads since releasing on 2020-03-20. Since that time, there have been a number of issues building in the backlog, pending feature enhancements that the community has worked on, pull requests submitted, and much more that have not been actioned on as needed.
What's Next
3.0.0 Release
The first thing that we need to do is provide an updated release. As some may know, one of the major changes with PSGSuite 2.0.0 was the switch to using the .NET SDKs from Google for API interaction. This is a switch that continues to prove worthwhile in terms of scalability and ease of continued integration. Due to taking on heavy dependencies with Google's .NET SDKs, however, we are subsequently heavily bound to the versions of .NET that the SDKs themselves also support. At some point during the release gap, Google removed support for .NET Framework 4.5, which Windows PowerShell is still compiled with, meaning that any new release of PSGSuite would no longer support Windows PowerShell (at least). After discussion amongst the maintainer team, we've determined to bump the minimum required version of PowerShell for PSGSuite to the current LTS version of PowerShell itself (7.4)
Beyond
From this point, we will start addressing the backlog of issues and prioritizing work based on interest, support and/or overall impact in GitHub Projects (work in progress).
Expect normal release cadences to resume, although we're still figuring out how often that "normal" may be 🙂 .
Contributors are always appreciated, we are also happy to consider additional maintainers! Please reach out to @scrthq, @jgeron-suhsd, or @FISHMANPET for more info.
It is great to see some updates coming through. Great work everyone.
Concerning the requirement for Powershell v7+. I was under the impression that Windows Powershell (v5.1) and Powershell (v7+) both support using .netstandard 2.0 libraries? It appears that the Google APIs are released with a .netstandard 2.0 support, so I would have thought Windows Powershell was still compatible?
Please, tell me how I am wrong though as this is an area that I don't know much about.
The v7 requirement isn't a huge issue for me, I am more trying to understand how it all works.
@mbhs-josh Excellent question! You are correct that they support netstandard2.0, but the minimum version of .NET Framework netstandard2.0 supports is .NET 4.6.1, unfortunately 🙁
Windows PowerShell was never built on a version of .NET greater than 4.5 (first sentence here).
There is always the possibility of switching back to REST directly, but we'd need to figure out an alternate approach for some of the function generation we're doing based on the .NET class/method signatures that offered the same level of scalability we currently see from it.
Thanks for the link. It was an informative read.
I am still a bit confused though, I understand that Windows PowerShell was built on .NET 4.5 but I also understand that it uses the .NET Common Language Runtime (CLR) which allows it to use a combination of supported .NET framework versions that are installed.
On a machine in front of me that has .NET 4.8 installed, Windows PowerShell is reporting a CLR version of 4.0.30319.42000. This page here indicates that this version supports .NET versions 4.6+.
If you are able to answer, am I understanding correctly that theoretically it would be possible to safely use netstandard2.0 libraries with Windows PowerShell on machines that have .NET 4.6+ installed? With the obvious caveat that it would be a difficult depdendency to enforce for a PowerShell module.
Note, I am not advocating that PSGSuite should still support Windows PowerShell, I saw the opportunity to try and learn more about how this all works and figured I would ask some questions.
Thanks!
PS. Just realized that I am using a different account. This is @Foggy2 .
PSGSuite 3.0.0-beta is on the PSGallery, it has to be installed with the -AllowPrerelease parameter.
This project hasn't been getting the attention it deserves as I stepped in and offered to help, but have been unable to devote the time that I'd like and admittedly and have been a little intimidated coming in on the project and doing the work that needs to be done. @scrthq has mostly moved onto other things and I don't think he relies on this project much in his day-to-day anymore.
All that said, I've been rolling the beta in production here since we first released it 7 months ago and it's been going well, so we'd probably be fine to take it out prerelease.
All that said, I've been rolling the beta in production here since we first released it 7 months ago and it's been going well, so we'd probably be fine to take it out prerelease.
Hi @jgeron-suhsd FYI. The v3 beta version broke the OAuth (Client Secrets) authentication method. Google made a change to their OAuth arrangements a while back which resulted in the method used in PSGSuite being deprecated and removed from the API library.
I have fixed that in #405 but I have also made a number of other, very significant changes that we would need to work through before that could be merged.
I just realized that I never raised an issue for the broken OAuth, I'll raise one now with a few more details.
I don't think I've ever leveraged the OAuth authentication method myself. But happy to have the help to get it where it needs to be and try to coordinate releases and PRs as a co-maintainer of the project.