Microsoft reported that it earned a net income of $35.8 billion on revenues of $90 billion in the quarter ending June 30, 2026.

The post Microsoft Earnings Up 18 Percent to $90 Billion appeared first on Thurrott.com.

I’ve been playing around with AT Protocol. The posts on this site are now published to standard.site, and I’ve written a (very basic) WordPress plugin to display posts from my PDS on the Now page of this site.

As a developer, I’ve spent a good chunk of my working life building apps that stored things in databases, and dealing with the pain of migrating things from one database to another. With that background I’m excited about the ways atproto can solve the many pains I’ve encountered, but I also had a bunch of questions as I started to build things. For example, what do I store in my app and what goes into the PDS? What is the relationship between Bluesky and my data? What about big files like images or video?

If you are asking similar questions, I’d recommend listening to the recent episode of Syntax.fm with Dan Abramov, who very clearly articulates the answers to all of these questions, and more. I’d figured a lot of these things out, but after listening to Dan I’d be much more confident in explaining how this works to someone else, without a lot of handwaving!

If you are interested in what else I’m reading while learning about AT Protocol, I’ve just started a collection on Semble (another atproto app) to store interesting atproto links I find.

Starting November 2026 the AWS SDK for .NET will adopt a new annual schedule of adding and removing .NET build targets for the SDK.

In April 2025, we released V4 of the AWS SDK for .NET. A major goal of V4 was to modernize the .NET targets supported by the SDK so we can start taking advantage of modern high-performance .NET APIs. Since the V4 release, we have continued working with the community to take advantage of modern .NET and improve performance. Here are some performance improvement PRs from this year.

Now that V4 has established a modern foundation for the AWS SDK for .NET, we want to ensure it stays current. To do this, we are defining a predictable annual schedule for adding and removing .NET targets from the SDK.

Background

Across AWS there are many .NET NuGet packages published, and not all packages are considered part of the AWS SDK for .NET. The NuGet packages that are referred to as the AWS SDK for .NET are the core library AWSSDK.Core package and the individual AWS service packages that follow the naming pattern AWSSDK.<service-name> such as AWSSDK.S3 or AWSSDK.SQS.

Today, the V4 AWS SDK for .NET builds for the following targets:

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET Core 3.1
• .NET 8

The .NET Framework 4.7.2 target supports our .NET Framework customers. There is no end-of-life schedule for .NET Framework 4.7.2 from Microsoft, and we will continue to include this target for the foreseeable future. The .NET Standard 2.0 target is currently required for AWS Tools for PowerShell. That means the .NET Standard 2.0 target will also be included for the foreseeable future.

As documented by the Microsoft .NET support cycle modern cross-platform .NET has new major versions released every November, with every other year being an LTS (Long Term Support) release with 3 years of support and the alternating years being STS (Standard Term Support) with 2 years of support.

The case for a defined schedule

Until now, the SDK has only added a new .NET build target when there were new APIs in a .NET release that we wanted to take advantage of. For example, in 2023, we added the .NET 8 target to support Native AOT. This approach works because the SDK only depends on the base .NET runtime, which maintains very strong backward compatibility between releases.

However, this ad hoc approach has led to several issues:

• Customer confusion: Customers see in NuGet the latest target is .NET 8 and conclude that we haven’t updated the SDK for .NET 10, thinking we are behind.
• Unclear target removal: Without a defined schedule, old .NET targets linger with the SDK building technical debt that reduces the amount of effort that can be spent optimizing for the latest .NET version. These old .NET targets also make it harder for community members to build the SDK because it requires them to have versions well past end of support installed in their development environment.
• Delayed feature adoption: Without a schedule, new .NET features require a one-off decision about whether to add a new target, which can result in features being delayed indefinitely with no clear timeline for adoption.

A defined schedule addresses all of these issues by setting clear expectations for both our team and the users of the SDK.

The schedule

Every year, the SDK will be updated to add the build target for the current year’s release. We will attempt to align as closely as possible with the .NET November release cycle but may fall back to December depending on demands for other priorities, particularly for AWS re:Invent. The list of .NET targets will contain at most two LTS versions. If adding the new target would bring the total to three LTS versions, the oldest LTS is removed along with any STS versions that precede the new oldest LTS version.

This schedule gives an additional year of AWS SDK support from AWS after Microsoft has declared end of life for the .NET runtime. That is six months longer than the AWS SDK’s documented Maintenance policy because it provides a better alignment with the .NET yearly release cycle.

Each yearly update of .NET targets will be released as a new minor version of the SDK. In November 2026 we will release V4.1; in November 2027 V4.2; and so on. While the product version receives the minor version bump, the assembly version compiled into the binary will remain 4.0.0. The assembly version is part of the assembly identity. Other assemblies bind to this identity when referenced as a dependency during compilation. This means third-party libraries compiled against V4.0 will continue to work without recompilation because the assembly identity doesn’t change. This follows the same versioning practice we used with V3, ensuring backward compatibility for all third-party libraries.

Yearly target examples

The following examples show how the target list evolves each year. LTS versions are bolded and removed targets are struck out.

November 2026 (V4.1)

Because this is the first year the schedule applies, it will be handled as a special case. We will add the .NET 10 LTS version and remove .NET Core 3.1, which has been end of life since December 2022. By the schedule, we would also add the STS .NET 9 target, but adding a target at the time it is going out of support is unnecessary.

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET Core 3.1 (LTS) (Removed)
• .NET 8 (LTS)
• .NET 10 (LTS)
• .NET 11 (STS)

November 2027 (V4.2)

The .NET 8 target is removed because it would become a third LTS version.

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET 8 (LTS) (Removed)
• .NET 10 (LTS)
• .NET 11 (STS)
• .NET 12 (LTS)

November 2028 (V4.3)

Only the new .NET 13 STS is added and nothing is removed. You can continue to use .NET 10 and .NET 11 for another year even though they have reached Microsoft end of life.

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET 10 (LTS) (Microsoft end of life)
• .NET 11 (STS) (Microsoft end of life)
• .NET 12 (LTS)
• .NET 13 (STS)

November 2029 (V4.4)

The new .NET 14 LTS is added, triggering the removal of .NET 10 (the oldest LTS) and .NET 11 (STS older than the new oldest LTS).

• .NET Framework 4.7.2
• .NET Standard 2.0
• .NET 10 (LTS) (Removed)
• .NET 11 (STS) (Removed)
• .NET 12 (LTS)
• .NET 13 (STS)
• .NET 14 (LTS)

What this means for you

For most of you, this schedule is transparent. NuGet will resolve the best matching target for your application automatically. If you are using a .NET version that is no longer a build target in the latest SDK minor version, you have two options:

1. Stay on the previous SDK minor version. There will be no new releases for the previous minor version, so you will not receive any more SDK updates.
2. Update to the latest SDK version. NuGet will resolve to the .NET Standard 2.0 version of the SDK. For most use cases, .NET Standard 2.0 provides the functionality you need, though it will be missing some target-specific optimizations. For example, if you were using .NET 8 and updated to V4.2 in 2027 when .NET 8 was dropped, you would fall back to .NET Standard 2.0, losing Native AOT support and .NET 8+ performance optimizations.

Conclusion

This schedule brings predictability to how the SDK evolves with the .NET ecosystem. You will always know that the latest .NET version is supported by the end of the year of its release, and you will have a full year of additional AWS SDK support after Microsoft ends support for a .NET version.

Thank you for your interest in the new Azure SDKs! We release new features, improvements, and bug fixes every month. Subscribe to our Azure SDK Blog RSS Feed to get notified when a new release is available.

You can find links to packages, code, and docs on our Azure SDK Releases page.

Release highlights

The Azure SDK for Rust adds Storage Shared Access Signature support

Following the Azure SDK for Rust reaching general availability in May and completing its 1.0.0 foundation in June, this month brings the first client capability built on top of that stack: azure_storage_sas (0.1.0). The new crate is a user-delegation Shared Access Signature (SAS) builder for Azure Storage, letting Rust developers grant scoped, time-limited access to Blob, Queue, and other Storage resources without sharing account keys.

App Service domain and certificate management reach general availability for Python

Two paired management libraries hit their first stable release this month: Domain Registration 1.0.0 and Certificate Registration 1.0.0. Together they give Python developers a supported, stable client for purchasing and managing App Service domains and provisioning and managing App Service certificates, so custom-domain and TLS setup for web apps can be fully automated in code.

Azure Resource Health management reaches general availability for Python

The Resource Health 1.0.0 management library is now generally available. It gives Python developers a stable client for querying the availability and health status of Azure resources programmatically, which makes it straightforward to build automated health monitoring, alerting, and reporting on top of Azure Resource Health.

Azure Data Boundaries management reaches general availability for Python

The Data Boundaries 1.0.0 management library reaches its first stable release. It lets Python developers configure and manage tenant-level data boundary settings programmatically, supporting data-residency and compliance requirements such as the EU Data Boundary.

Initial stable releases

• Management Libraries for Python
  • Resource Management – Certificate Registration 1.0.0
  • Resource Management – Data Boundaries 1.0.0
  • Resource Management – Domain Registration 1.0.0
  • Resource Management – Kubernetes Configuration Flux Configurations 1.0.0
  • Resource Management – Monitor Workspaces 1.0.0
  • Resource Management – Network Function 1.0.0
  • Resource Management – Resource Health 1.0.0

Initial beta releases

• Management Library for Java
  • Resource Management – Resilience Management 1.0.0-beta.1
• Management Libraries for Python
  • Resource Management – Alert Processing Rules 1.0.0b1
  • Resource Management – Billing Trust 1.0.0b1
  • Resource Management – Commvault Content Store 1.0.0b1
  • Resource Management – Domain Services 1.0.0b1
  • Resource Management – Marketplace 1.0.0b1
  • Resource Management – Power Platform 1.0.0b1
  • Resource Management – Program Enrollment 1.0.0b1
  • Resource Management – Prometheus Rule Groups 1.0.0b1
  • Resource Management – Provider Hub 1.0.0b1
  • Resource Management – Resilience Management 1.0.0b1
• Client Library for Rust
  • Azure Storage SAS 0.1.0

Release notes

• All languages
• .NET
• Java
• JavaScript/TypeScript
• Python
• Go
• Rust
• C++
• Embedded C
• Android
• iOS

The post Azure SDK Release (July 2026) appeared first on Azure SDK Blog.

1207. This week, we look at the hidden linguistic history of Ontario with Sali Tagliamonte. We look at why euphemisms like "golly" and "gosh" are going the way of the dinosaur, the surprising connection between Northern Ontario and the Southern U.S., and how Canadian words like "gas bar" and "Muskoka chair" finally made it into the Oxford English Dictionary. This episode ran for Grammarpaloozians in February 2026. To get more bonus content, visit Patreon.com/GrammarGirl.

🔗 Join the Grammar Girl Patreon.

🔗 Share your familect recording in Speakpipe or by leaving a voicemail at 833-214-GIRL (833-214-4475)

🔗 Watch my LinkedIn Learning writing courses.

🔗 Subscribe to the newsletter.

🔗 Find an edited transcript.

🔗 Get Grammar Girl books.

| HOST: Mignon Fogarty

| Grammar Girl is part of the Quick and Dirty Tips podcast network.

• Audio Engineer: Dan Feierabend
• Director of Podcast: Holly Hutchings
• Advertising Operations Specialist: Morgan Christianson
• Marketing and Video: Nat Hoopes, Rebekah Sebastian
• Podcast Associate: Maram Elnagheeb

| Theme music by Catherine Rannus.

| Grammar Girl Social Media: YouTube. TikTok. Facebook. Threads. Instagram. LinkedIn. Mastodon. Bluesky.

Hosted on Acast. See acast.com/privacy for more information.