Bump Microsoft.Extensions.AI.Abstractions and 2 others - #34
Merged
Conversation
dependabot
Bot
added
.NET
Bumps Microsoft.Extensions.AI.Abstractions to 10.8.3 Bumps Quartz.Extensions.DependencyInjection from 3.18.2 to 3.19.1 Bumps Quartz.Extensions.Hosting from 3.18.2 to 3.19.1 --- updated-dependencies: - dependency-name: Microsoft.Extensions.AI.Abstractions dependency-version: 10.8.3 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: minor-and-patch - dependency-name: Quartz.Extensions.DependencyInjection dependency-version: 3.19.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch - dependency-name: Quartz.Extensions.Hosting dependency-version: 3.19.1 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: minor-and-patch ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
changed the title
dependabot
Bot
force-pushed
the
dependabot/nuget/minor-and-patch-745b9933fc
branch
from
July 29, 2026 22:23
17b4c12 to
c1d5e56
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pinned Microsoft.Extensions.AI.Abstractions at 10.8.3.
Release notes
Sourced from Microsoft.Extensions.AI.Abstractions's releases.
10.8.3
Packages in this release
Experimental API Changes
Experimental API behavior updates
ToolApprovalRequestContent.RequiresConfirmationso it no longer leaks into consumer source-generatedAIContentJSON metadata unless approval APIs are intentionally used (#7659).What's Changed
AI abstractions and serialization
RequiresConfirmationin source-generatedAIContentcontexts by using an internal JSON-included backing member while keeping the public experimental member ignored for source-generation metadata (#7659).Test Improvements
List<AIContent>contexts compile and round-trip without requiring MEAI001 suppression (#7659).Full Changelog
10.8.2
This servicing release updates Microsoft.Extensions.VectorData.ConformanceTests to 10.8.2 and includes targeted test framework migration fixes.
Packages in this release
What's Changed
AI
Acknowledgements
Full Changelog: dotnet/extensions@v10.8.1...v10.8.2
10.8.1
This servicing release updates the Microsoft.Extensions.AI, Microsoft.Extensions.AI.Abstractions, and Microsoft.Extensions.AI.OpenAI packages to 10.8.1 with two targeted fixes: correct tool-call/tool-result ordering when resuming approval-gated functions with service-managed chat history, and preservation of the OpenAI Responses reasoning item id for stateless (store=false) encrypted reasoning.
Packages in this release
What's Changed
AI
Acknowledgements
Full Changelog: dotnet/extensions@v10.8.0...v10.8.1
10.8.0
This release adds new experimental APIs to Microsoft.Extensions.AI.Abstractions and updates the OpenAI dependency to 2.12.0, alongside documentation, test, and repository maintenance.
Experimental API Changes
New Experimental APIs
AIFunctionNameAttributeandAIParameterNameAttribute#7610 by @jozkee (co-authored by @jeffhandley @Copilot)ToolApprovalRequestContent.RequiresConfirmation(MEAI001) #7549 by @javiercn (co-authored by @Copilot)What's Changed
AI
Vector Data
Documentation Updates
Test Improvements
Repository Infrastructure Updates
... (truncated)
10.7.0
v10.7.0 graduates the Microsoft.Extensions.Diagnostics.ResourceMonitoring.Kubernetes package to stable. The package registers a Kubernetes-aware
ResourceQuotaProviderthat reads the pod's CPU and memory requests and limits and exposes them toMicrosoft.Extensions.Diagnostics.ResourceMonitoringas baseline and maximum quotas, which then feed the request and limit dimensions of the published resource utilization metrics. The companionResourceQuotaandResourceQuotaProvidertypes inMicrosoft.Extensions.Diagnostics.ResourceMonitoringgraduate to stable in the same change so that consumers can implement custom quota providers without taking an experimental dependency.On the AI side,
Microsoft.Extensions.AI.OpenAImoves to OpenAI 2.11.0 and fixes a deserialization bug inToolJson.AdditionalPropertiesso that JSON SchemaadditionalPropertiesvalues shaped as sub-schema objects (for example{"type":"string"}) are preserved instead of throwing during deserialization.HostedFileContent.SizeInBytesandHostedFileContent.CreatedAtgraduate to stable since both values are consistently available across hosted-file providers, whilePurposeandScoperemain experimental as provider-shaped vocabulary.FunctionInvokingChatClientdrops a backward-compat path that auto-markedToolApprovalResponseContententries withInformationalOnly: true; consumers that need to continue accepting sessions serialized before #7468 can use the sampleApprovalHistoryNormalizingChatClientmiddleware added in the test project.Experimental API Changes
Now Stable
Microsoft.Extensions.Diagnostics.ResourceMonitoring.Kubernetespackage is now stable #7253ResourceQuotaandResourceQuotaProviderAPIs are now stable (previouslyEXTEXP0008) #7253HostedFileContent.SizeInBytesandHostedFileContent.CreatedAtare now stable (previouslyMEAI001) #7513What's Changed
AI
Diagnostics, Health Checks, and Resource Monitoring
Repository Infrastructure Updates
Acknowledgements
Full Changelog: dotnet/extensions@v10.6.0...v10.7.0
10.6.0
Version 10.6.0 stabilizes the response continuation token and background-response APIs in Microsoft.Extensions.AI.Abstractions. Most other AI work for May shipped in 10.5.1; this monthly release rolls those changes up alongside dependency updates and a small Resource Monitoring cleanup.
Experimental API Changes
Now Stable
MEAI001) #7512What's Changed
AI
Repository Infrastructure Updates
Acknowledgements
Full Changelog: dotnet/extensions@v10.5.2...v10.6.0
Commits viewable in compare view.
Updated Microsoft.Extensions.AI.Abstractions from 10.8.1 to 10.8.3.
Release notes
Sourced from Microsoft.Extensions.AI.Abstractions's releases.
10.8.3
Packages in this release
Experimental API Changes
Experimental API behavior updates
ToolApprovalRequestContent.RequiresConfirmationso it no longer leaks into consumer source-generatedAIContentJSON metadata unless approval APIs are intentionally used (#7659).What's Changed
AI abstractions and serialization
RequiresConfirmationin source-generatedAIContentcontexts by using an internal JSON-included backing member while keeping the public experimental member ignored for source-generation metadata (#7659).Test Improvements
List<AIContent>contexts compile and round-trip without requiring MEAI001 suppression (#7659).Full Changelog
10.8.2
This servicing release updates Microsoft.Extensions.VectorData.ConformanceTests to 10.8.2 and includes targeted test framework migration fixes.
Packages in this release
What's Changed
AI
Acknowledgements
Full Changelog: dotnet/extensions@v10.8.1...v10.8.2
Commits viewable in compare view.
Pinned Quartz.Extensions.DependencyInjection at 3.19.1.
Release notes
Sourced from Quartz.Extensions.DependencyInjection's releases.
3.19.1
Quartz.NET 3.19.1 is a small bug fix release with two targeted fixes:
DailyTimeIntervalTriggerno longer gets stuck in an infinite fire loop on DST spring-forward days, andStdSchedulerFactory.GetScheduler(schedName)now creates the scheduler when the name asked for is its own. There are no API or schema changes, so it is a drop-in upgrade from 3.19.0.Highlights
DailyTimeIntervalTriggerno longer spins on DST transition days —GetFireTimeAftercould return a time at or before the one it was given, which makesQuartzSchedulerThreadfire the trigger, compute the same next fire time, and fire again — pinning a CPU core and flooding the log. Two independent causes, both on a spring-forward day: the DST correction added for #1114 was applied to every interval size and in either direction (so every interval of an hour or less was affected, in every DST time zone), and the daily rollover toStartTimeOfDayreused whatever UTC offset the previous fire time carried (so in time zones that move the clock at midnight, such as Chile,StartTimeOfDay00:00 resolved to an instant before the transition — the same instant that was passed in). Verified across 3024 combinations of 12 time zones, both transitions, 21 intervals and 6 start times: 468 combinations produced non-advancing fire times before, none do now. (#3190, fixes #332)StdSchedulerFactory.GetScheduler(schedName)creates its own scheduler — asking a factory for the scheduler it is configured to produce returnednulluntil somebody had calledGetScheduler()first. It now creates it. Any other name stays a pure lookup, so probing for a scheduler somebody else owns still has no side effects, and the name comparison is case-insensitive to match howSchedulerRepositoryindexes names. The DI factory has behaved this way since #2845; this brings the property-configured factory in line. (#3188, reported in #2786, originally proposed in #360)What's Changed
Full Changelog: quartznet/quartznet@v3.19.0...v3.19.1
3.19.0
Quartz.NET 3.19.0 is a feature release: it adds node affinity for clustered scheduling, a fluent cron-expression builder, and richer
L/LWday-of-month expressions, plus clock-jump resilience and a modernized build and publishing pipeline. The public API is unchanged (all additions are additive), so it is a drop-in upgrade — with two things to note: the new node-affinity columns are an optional schema migration (the feature degrades gracefully without them), and a handful of previously-brokenL/LW/Wcron expressions now fire correctly (see below).Highlights
TriggerBuilder.WithPreferredNode(...); the node is preferred for acquisition but the trigger is still stolen on failover so it is never stranded if that node goes down. Adds optionalPREFERRED_NODE/PREFERRED_NODE_AUTOcolumns for ADO.NET job stores (database/schema_30_add_preferred_node.sql); when the columns are absent the scheduler logs a warning and behaves exactly as before. (#3013, #3144)CronExpressionBuilder— compose cron expressions programmatically, one field at a time, instead of hand-writing the string — handy when a schedule is assembled from user input such as a scheduling UI. (#3139)LandLWcombinable with other day-of-month values — the day-of-month field now accepts expressions such as1,15,Land the newLW-n/L-nWgrammar. This also corrects several previously-buggy edge cases:29W/31Wno longer silently skip short months,L-30Wno longer throws mid-schedule, and1,15Wnow appliesWto each day rather than only the first. These corrections change the fire times of a few expressions that were previously broken — review any storedL/LW/Wday-of-month expressions. (#2759)Note for
CronScheduleBuilderusers:AtHourAndMinuteOnGivenDaysOfWeek/WeeklyOnDayAndHourAndMinutenow emit textual day-of-week names (e.g.MON,WEDrather than2,4). The schedules are identical, but the generatedCRON_EXPRESSIONstring differs — relevant only if you compare stored cron strings byte-for-byte.What's Changed
Full Changelog: quartznet/quartznet@v3.18.2...v3.19.0
Commits viewable in compare view.
Pinned Quartz.Extensions.Hosting at 3.19.1.
Release notes
Sourced from Quartz.Extensions.Hosting's releases.
3.19.1
Quartz.NET 3.19.1 is a small bug fix release with two targeted fixes:
DailyTimeIntervalTriggerno longer gets stuck in an infinite fire loop on DST spring-forward days, andStdSchedulerFactory.GetScheduler(schedName)now creates the scheduler when the name asked for is its own. There are no API or schema changes, so it is a drop-in upgrade from 3.19.0.Highlights
DailyTimeIntervalTriggerno longer spins on DST transition days —GetFireTimeAftercould return a time at or before the one it was given, which makesQuartzSchedulerThreadfire the trigger, compute the same next fire time, and fire again — pinning a CPU core and flooding the log. Two independent causes, both on a spring-forward day: the DST correction added for #1114 was applied to every interval size and in either direction (so every interval of an hour or less was affected, in every DST time zone), and the daily rollover toStartTimeOfDayreused whatever UTC offset the previous fire time carried (so in time zones that move the clock at midnight, such as Chile,StartTimeOfDay00:00 resolved to an instant before the transition — the same instant that was passed in). Verified across 3024 combinations of 12 time zones, both transitions, 21 intervals and 6 start times: 468 combinations produced non-advancing fire times before, none do now. (#3190, fixes #332)StdSchedulerFactory.GetScheduler(schedName)creates its own scheduler — asking a factory for the scheduler it is configured to produce returnednulluntil somebody had calledGetScheduler()first. It now creates it. Any other name stays a pure lookup, so probing for a scheduler somebody else owns still has no side effects, and the name comparison is case-insensitive to match howSchedulerRepositoryindexes names. The DI factory has behaved this way since #2845; this brings the property-configured factory in line. (#3188, reported in #2786, originally proposed in #360)What's Changed
Full Changelog: quartznet/quartznet@v3.19.0...v3.19.1
3.19.0
Quartz.NET 3.19.0 is a feature release: it adds node affinity for clustered scheduling, a fluent cron-expression builder, and richer
L/LWday-of-month expressions, plus clock-jump resilience and a modernized build and publishing pipeline. The public API is unchanged (all additions are additive), so it is a drop-in upgrade — with two things to note: the new node-affinity columns are an optional schema migration (the feature degrades gracefully without them), and a handful of previously-brokenL/LW/Wcron expressions now fire correctly (see below).Highlights
TriggerBuilder.WithPreferredNode(...); the node is preferred for acquisition but the trigger is still stolen on failover so it is never stranded if that node goes down. Adds optionalPREFERRED_NODE/PREFERRED_NODE_AUTOcolumns for ADO.NET job stores (database/schema_30_add_preferred_node.sql); when the columns are absent the scheduler logs a warning and behaves exactly as before. (#3013, #3144)CronExpressionBuilder— compose cron expressions programmatically, one field at a time, instead of hand-writing the string — handy when a schedule is assembled from user input such as a scheduling UI. (#3139)LandLWcombinable with other day-of-month values — the day-of-month field now accepts expressions such as1,15,Land the newLW-n/L-nWgrammar. This also corrects several previously-buggy edge cases:29W/31Wno longer silently skip short months,L-30Wno longer throws mid-schedule, and1,15Wnow appliesWto each day rather than only the first. These corrections change the fire times of a few expressions that were previously broken — review any storedL/LW/Wday-of-month expressions. (#2759)Note for
CronScheduleBuilderusers:AtHourAndMinuteOnGivenDaysOfWeek/WeeklyOnDayAndHourAndMinutenow emit textual day-of-week names (e.g.MON,WEDrather than2,4). The schedules are identical, but the generatedCRON_EXPRESSIONstring differs — relevant only if you compare stored cron strings byte-for-byte.What's Changed
Full Changelog: quartznet/quartznet@v3.18.2...v3.19.0
Commits viewable in compare view.