deps: Bump the dotnet-dependencies group with 19 updates by dependabot[bot] · Pull Request #408 · Ngonie69/ShopInventory

Quartz.NET 4.1 is an additive minor: every public change is a new type, a new member on a type we own, or a default interface member; the schema is 4.0's; a 4.0 application upgrades by changing the version. The headline is that a scheduler can now be added to, removed from and restarted in a running container — the one item the 4.0 roadmap deferred as "a 4.1 concern" — and around it the additive follow-ups filed during the 4.0 release candidates, an API reference for 4.x, and an honest Wolverine page now that Wolverine has a cron of its own.

dotnet add package Quartz --version 4.1.0

Highlights

Schedulers can be added, removed and restarted while the host runs — ISchedulerRuntime (it extends ISchedulerRegistry, as the 4.0 guide promised) builds a scheduler from a recipe into a container of its own that resolves the application's services, jobs and options from the application's container, binds it where the HTTP API, the dashboard and the health checks already look, drains it before it is replaced, and refuses the cases that cannot be made safe: a name the container registered, a bound name, a recipe that supplies an instance part, a restart whose drain gave up. ISchedulerFactory.LookupScheduler now builds a registered-but-unstarted scheduler on lookup. A restart builds the next generation first (a configuration error leaves the old one running), drains the old one within SchedulerRestartOptions.DrainTimeout (30 s by default) and only then initialises the new store — because the store's recovery sweep is per scheduler name, not per instance — and a drain that gives up leaves the name shut down and reported with no status until the next Restart finishes the job. A recipe that hands over a job store, thread pool, job factory or instance-id generator as an object is refused before anything is built, since a shut-down instance cannot be re-initialised. (#3338; add/remove #3725, restart #3734)
Cron — MON/2 parses and means what 2/2 means (a step through the week, not 3.x's fortnight), and MON-FRI/2 is 2-6/2 where 4.0 silently read it as MON-FRI. (#3732, #3733 [85214e4499…e29f7c4283]). The century walk of CronCalendar.GetNextIncludedTimeUtc (#3690) shipped in 4.0.1.
HTTP API — POST …/triggers/{group}/{name}/update-details edits a trigger in place (description, priority, job data, calendar, misfire instruction with its family, preferred node, execution group, retry policy; a field absent from the body is left alone and a null clears it), and HttpScheduler.UpdateTriggerDetails no longer throws — Context and ListenerManager are the two members a wire cannot carry (#3681, #3735). take says in the OpenAPI document why it is a string: a page size, or all for everything up to MaxPageSize (#3682, #3736). GetStatus(ct) and GetSchedulerInstanceId(ct) are the asynchronous twins of the two IScheduler properties a wire cannot answer without blocking — default interface members that answer the property locally, one round trip on HttpScheduler, and on the container's deferred scheduler they build it on first use where the properties throw (#3684, #3738). QuartzHttpApiOptions.IsJobTypeAllowed and its dashboard twin let an operator name which job types a request may schedule — a predicate over the type name as the request spelled it, never a resolved type; a refused name is a 403 naming the type and a warning in the log, and the default is unchanged (#3685, #3741).
Scheduling files — a trigger's preferred node can be declared in quartz_jobs.json, in the Quartz:Schedule section and in the XML file (<preferred-node>; * pins it to whichever node fires it first), and the XML format catches up with <execution-group> and <retry-policy>. The schema stays 2.0: the elements are optional and a 3.x file loads unchanged. The freeze on the XML format is redrawn as a freeze on trigger kinds, not settings. (#3683, #3739)
API reference for 4.x is published again at https://docs.quartz-scheduler.net/apidoc/4.x/, generated with docfx from the XML documentation every public member carries, and a doc comment that no longer matches its member fails the docs build. (#3686, #3740)
A scheduler reached over HTTP is a supported dashboard target, history included — AddQuartzDashboard() beside AddQuartzHttpClient("acme", …) now fronts the scheduler in the other process honestly: it is listed with the new origin Remote, every page drives it, the History page and the misfire tile read the history the target's process keeps, and Live Logs says what a wire does not carry yet. Underneath: the scheduler repository no longer reads a remote scheduler's Status while holding its lock — one unreachable target used to stall every scheduler lookup in the process, the HTTP API's own included, for the client's timeout — the registry asks all schedulers concurrently under one two-second budget and reports Unknown for the ones that did not answer, the pages page instead of asking for everything, and a second AddQuartzHttpClient under the same name is refused rather than silently winning. Execution history is now Quartz's rather than the dashboard's: IExecutionHistoryStore in core with an in-memory default bounded by age and count, a recorder AddQuartzExecutionHistory() installs against every scheduler, three GET …/schedulers/{name}/history/… routes the HTTP API serves, and a read-only reader of them that AddQuartzHttpClient registers per target. QuartzHttpApiOptions.ReadOnly turns the whole mutating surface of the API off in one switch — mutation is a property of the route, so the two bulk fetches stay reads. The design for the rest — live events over the wire, an audit of operator actions, store-attached and dial-out targets, a fleet pane — is recorded on #3387 and filed as 4.2 issues (#3768–#3775). (#3387, #3776)
Who changed what is on record. Every mutating HTTP API request that succeeds logs one Information line, 9007, naming the caller (HttpContext.User.Identity.Name, or (anonymous)), the operation, the scheduler and the route — until now a POST …/shutdown that worked was recorded nowhere. The dashboard's Action Log entries and their 9100/9101 lines now say where an action landed: the scheduler's origin, the node behind it, and whether the action was node-local (start, stand-by, shutdown and interrupting a firing) — and interrupting a firing from Currently Executing is recorded at all, which it was not. (#3769, #3784)
The Wolverine page no longer says Wolverine has no cron: since 6.34 it does (opts.Schedules.ScheduleRecurring, over Cronos), and the page now puts the two side by side in one table, says plainly when Wolverine's own schedule is the right answer, and keeps the recipe for what a Quartz trigger adds — with a seventh example part running Wolverine's schedule beside Quartz's. (#3719, #3737)

Public API — additive only

Added	What it is
`ISchedulerRuntime : ISchedulerRegistry` — `Add`, `Remove`, `Restart`	schedulers in a running container; resolve either interface and you get the same object
`SchedulerAddOptions`, `SchedulerRestartOptions` (readonly record structs), `SchedulerRestartException`	their options and the one refusal a caller can act on
`IScheduler.GetStatus(ct)`, `IScheduler.GetSchedulerInstanceId(ct)` — default interface members	the asynchronous twins of the two properties; a scheduler written outside this repository needs no change
`HttpScheduler.GetStatus` / `GetSchedulerInstanceId` overrides	one round trip each, no blocked thread
`QuartzHttpApiOptions.IsJobTypeAllowed`, `QuartzDashboardOptions.IsJobTypeAllowed`	an allow-list over the job-type name a request spells
`SchedulerOrigin.Remote`; `SchedulerRegistration.SchedulerInstanceId` (`init`)	a scheduler reached through a proxy, and the node a listing asked it for — asynchronously, under a deadline, never through the blocking property
`QuartzHttpApiOptions.ReadOnly`	every mutating route answers `403` problem details; the two bulk fetches stay reads
`QuartzHttpApiOptions.EventStreamHeartbeatInterval`	how long the event stream may be silent before a heartbeat frame; 15 s by default, set it below the proxy's idle timeout
`IExecutionHistoryStore`, `ExecutionHistoryEntry`, `MisfireHistoryEntry`, `ExecutionHistoryQuery`, `MisfireHistoryQuery`, `ExecutionHistoryOptions`, `AddQuartzExecutionHistory()`	the history seam in core; `IDashboardHistoryStore` keeps working as its adapter in both directions

Nothing was removed or reshaped (v4.0.1..v4.1.0 baseline diff: 96 added lines, 0 removed). The one dependency change: Quartz now depends on Microsoft.Extensions.Logging.Abstractions rather than Microsoft.Extensions.Logging; an application that took LoggerFactory or AddLogging transitively from Quartz adds the package itself (#3730, #3745).

Behaviour changes worth noting

MON/2 parses (4.0 refused it; 3.x read it as every second week) and MON-FRI/2 fires on three days, not five — neither can be reported to you, both parse; the migration guide's 4.0 → 4.1 section has the audit query. A QuartzSchedulerBuilder with a provider registered but no factory refuses to build (see #3730). GetNextInvalidTimeAfter returns null where it used to return a valid instant (4.0.1). A shut-down container scheduler injected as IScheduler re-points to the generation ISchedulerRuntime.Restart built. Mapping the HTTP API now records execution history in memory, bounded (24 h, 2,000 rows per scheduler); ExecutionHistoryOptions.MaxEntriesPerScheduler = 0 records nothing. AddQuartzHttpClient throws on a scheduler name it already registered. A 4.0 client parsing GET …/schedulers from a 4.1 host that fronts a proxy sees the origin "Remote" it does not know — upgrade the client. AddQuartzDashboard() no longer registers DashboardLiveEventsPlugin; a reverse proxy needs to forward {DashboardPath}/hub only for SignalR clients of your own, not for the pages. Log events 9100 and 9101 end with (origin …, node …) — a pipeline parsing the old template needs the new one.

Also

A failed cluster check-in is retried inside the window its peers give it — a peer writes a node off once CheckinInterval + CheckinMisfireThreshold has passed since the row it last wrote (15 s on the defaults), and the cluster manager's sleep after a failed check-in was floored at DbRetryInterval, also 15 s, so one database blip during a check-in had a live node recovered by its peers: its next row went out at 22.5 s, 7.5 s after they had stopped trusting it. Inherited from Java Quartz. A failed check-in is now retried inside what is left of the window — half of it each time, never later than DbRetryInterval — and only once the window has closed does the ordinary back-off apply; the retries are timed from the last check-in that reached the database, not from the stamp a failed read of the state table leaves. Defaults are unchanged, so the 15-second failover latency stays. CheckinMisfireThreshold past the timer ceiling is now refused at startup, like CheckinInterval. (#3777, #3778; 3.22 carries the same change on 3.x)
- Behavior change worth noting: a node whose check-in fails makes up to ~9 connection attempts and logs three error lines in the first 15 s of an outage instead of one, then backs off DbRetryInterval as before.
A shutdown that does not wait for its jobs no longer loses a firing — the new two-node Redis fixture caught it: Shutdown(waitForJobsToComplete: false) closed the thread pool to new work before the scheduler loop had finished its iteration, so a firing the loop had already committed to the store (fired-trigger row written, trigger advanced) was refused by the pool and never ran — only RequestRecovery would ever have replayed it — and a completion reported after the store had closed was aborted, leaving the trigger BLOCKED for a peer's cluster recovery to settle. The loop is now halted and awaited before anything it depends on is torn down, and an unwaited shutdown gives the executions it dispatched two seconds to report their completions before the store closes; the waited form drains as before. On the fixture: 160 of 160 firings with a node leaving mid-run without waiting. (#3746, #3754)
- Behavior change worth noting: Shutdown(waitForJobsToComplete: false) — the hosted service's default — can take up to two seconds longer when a job is in flight.
A job that requested recovery is recovered after a hard kill when the application declares its jobs and triggers through AddJob/AddTrigger. Declared content is applied at creation, and a trigger the store already held was applied as a reschedule that deleted every fired-trigger row of the key — before Start(), so the recovery sweep found nothing to recover. ReplaceTrigger now deletes the trigger row only; unscheduling still takes the fired rows with it, and the replacement of a trigger whose job disallows concurrent execution is stored BLOCKED behind an execution still in flight rather than WAITING beside it. The clustered case had a second defect: a node's first check-in handed its own state row to recovery, and the deferral grace period judged that row by its old timestamp — the node's own record is never deferred now. A SQLite reproduction of the restart runs without Docker. (#3759)
A lock wait says how long it has been waiting, and every statement can be bounded. A lock statement queued behind a dead database session — a node whose network was cut while it held TRIGGER_ACCESS — returns nothing and throws nothing, so a cluster stopped scheduling in silence. DbLockHandler now logs event 3716 once per acquisition that outlives AdoJobStoreOptions.LockWaitWarningThreshold (30 s by default; null reports nothing), every acquisition is timed on quartz.jobstore.lock.wait.duration, and quartz.jobStore.commandTimeout — which 3.22 adds — translates to AdoJobStoreOptions.CommandTimeout where it used to be accepted and silently dropped. Neither ends the wait; a command timeout does, and the troubleshooting page says how to tell the case apart in each database and which server-side settings free the lock. (#3764, #3766)
A failed check-in is retried inside the window its peers give it. A peer writes a node off once interval + threshold has passed (15 s on the defaults), and the cluster manager's sleep after a failed check-in was floored at DbRetryInterval — also 15 s — so a check-in that failed at 7.5 s was next attempted after the peers had already recovered the node: fired rows deleted, recovering jobs fired again, [DisallowConcurrentExecution] no longer holding. Inherited from Java Quartz rather than a regression. While the window is open a failed check-in is retried inside it, half of what is left each time; only once it has closed does the ordinary back-off apply. Defaults and the documented 15-second failover latency are unchanged, and threshold >= DbRetryInterval is no longer a relation an operator has to know about. The 3.x configuration reference's clusterCheckinInterval default (7500, not 15000) and the missing clusterCheckinMisfireThreshold row were fixed on the way. (a5b2197e5d)
Two schedulers locking through Redis are proven not to double-fire — the redis integration leg now runs two clustered nodes over one PostgreSQL store with RedisLockHandler as the only mutual exclusion, 250 firings across a [DisallowConcurrentExecution] job and an ordinary one, and asserts no firing doubled, none was lost, the non-concurrent job never overlapped and both nodes fired; a second fixture shuts one node down mid-run and checks the survivor and the closed multiplexer. 4.0.0 listed Quartz.Extensions.Redis as the least exercised package; it no longer is. (#3722, #3744)
3.21.0 on the 3.x line carries the three fixes held back from 3.20.1 (see its notes).
A misspelled quartz.jobStore.* key fails startup instead of being ignored. 4.0 read the keys it knew into typed options and did nothing with the rest, so quartz.jobStore.dbRetryIntreval started the scheduler with the default in force and said nothing — which is also how quartz.jobStore.commandTimeout went missing before it was bridged. A persistent store now refuses a key under that prefix that nothing reads, by name, where a misconfiguration already fails: Unknown configuration property 'quartz.jobStore.dbRetryIntreval'. It is not a setting of the ADO.NET job store …. quartz.checkConfiguration = false allows it through, as for every other unknown key; a store of your own keeps failing in the binder that writes leftover keys onto it, as 3.x did. (#3767)
- Behavior change worth noting: a configuration file carrying a quartz.jobStore.* typo that 4.0 tolerated stops the scheduler from starting.
  ... (truncated)

4.0.1

Quartz.NET 4.0.1 is a maintenance release about getting to 4.0: nothing about how a trigger fires changed, the public API is untouched (the baselines did not move), and the schema is 4.0's. Five days after 4.0.0 an audit of every public dependency-bot pull request that touched a Quartz package found two reasons an upgrade never got as far as compiling, both of them ours, both fixable in a patch — one gap in the migration guide for F# — and, found by the rc.1 security gate and moved forward, a cron calendar that could take a century to answer.

dotnet add package Quartz --version 4.0.1

What changed

A consumer one servicing patch behind restores 4.0.1 — 4.0.0's package manifest floored every Microsoft.Extensions.* dependency at 10.0.11, the newest patch on the day it was built, so a project pinned at 10.0.9 or 10.0.10 hit NU1605 "detected package downgrade" before a line of source compiled. Every floor is now the lowest version of its major that the code compiles against and that carries no advisory: 10.0.0 for the framework extensions, 13.0.2 for Newtonsoft.Json (13.0.1 reflects over TimeOnly member by member and a job data map loses its seconds — a test said so), 1.15.3 for OpenTelemetry.Extensions.Hosting (the first version whose OpenTelemetry.Api carries no advisory), 3.0.0 for StackExchange.Redis and 7.0.0 for TimeZoneConverter. The library is built against those floors, so the claim is checked on every build, and a test refuses a floor that creeps up. (#3717, c9ecf892bd)
A grouped dependency update can reach 4.x — the four packages 4.0 folded into Quartz (Quartz.Extensions.DependencyInjection, Quartz.Extensions.Hosting, Quartz.Serialization.SystemTextJson, and Quartz.Serialization.Json, whose successor is Quartz.Serialization.Newtonsoft) had no 4.0.0, so a bot that groups Quartz with any of them resolved the group to the newest version every member has — 3.20.1 — and closed the 4.0.0 pull request it had already opened as superseded, with green checks. From 4.0.1 those four ids carry an empty package at every 4.x version: no assembly, one dependency on the replacement, a readme that says to remove the reference. The migration guide's instruction stands — remove them — but the upgrade is now offered. Quartz.OpenTracing and Quartz.OpenTelemetry.Instrumentation deliberately have no such package: neither has a 4.x replacement, and an empty one would hide that. (#3717, c28f213cbd)
- Seen in the wild before the fix: efibs/GeoClubBot#304 → #305, CactuseSecurity/firewall-orchestrator#5238 → #5240, US-EPA-CAMD/easey-quartz-scheduler#568.
CronCalendar.GetNextIncludedTimeUtc no longer walks a century one second at a time — it asked CronExpression.GetNextInvalidTimeAfter for the end of an excluded run, and that method stepped through the run one second per full cron computation; for an expression that excludes everything (* * * * * ?) the walk ran to the give-up year, roughly three billion computations, on a public member. The next non-matching instant is now read off the expression's own field sets — second, minute, hour, day, month, year — with each skip verified against the time zone's clock so a repeated fall-back hour is never stepped over. An expression that fires every second answers null, and the calendar turns that into a SchedulerException naming the expression instead of hanging. The unchanged next-fire-time path measures the same as before; the changed method is 76–86 % faster on the benchmark corpus. (#3690, a125809ba9, 4d60904c6f)
- Behavior change worth noting: GetNextInvalidTimeAfter returns null where it used to return a valid instant after giving up, and a CronCalendar whose expression excludes every instant now fails fast with SchedulerException.
The migration guide has a section for F# — an F# implementer sees four errors no C# project does (FS0856 on IJob.Execute's arity, FS0041 on ScheduleJob overload resolution, Async.AwaitTask with a ValueTask, FS0039 for StdSchedulerFactory), each quoted with its fix, and every sample is copied from a compiled example project the build keeps honest. (#3718, 1b97b49f41, aff4feac69)

Upgrading

From 4.0.0: dotnet add package Quartz --version 4.0.1; nothing else. From 3.x: the 4.x migration guide is unchanged in substance; if your bot has been landing 3.20.1 "upgrades", this is the release that lets it offer 4.x.

Full changelog: quartznet/quartznet@v4.0.0...v4.0.1

4.0.0

Quartz.NET 4.0 targets net10.0, is asynchronous and container-built throughout, and trims a public surface that had accumulated for a decade. It is a major version with extensive breaking changes and a mandatory schema migration. This page is the short form; the detail lives in the docs:

4.x migration guide — start at Start here; every breaking change with before and after, an ordered runbook for a running deployment, and an appendix that indexes every removed name
Database schema changes — what to run, per version and per database
Before you go live — the production checklist
Quick start — if you are starting something new, none of the above applies

dotnet add package Quartz

Highlights

net10.0 only — no netstandard2.0 build, no Full Framework, no .config support.
The container builds the scheduler. Dependency injection and hosting are part of the core Quartz package; StdSchedulerFactory, quartz.config discovery and the process-global SchedulerRepository.Instance / DBConnectionManager.Instance are gone. Flat quartz.* keys still work, translated to typed options by the one component that understands them, and a misspelled key is refused with a message rather than ignored. Options are validated at startup, so a bad value fails Host.Build() with every failure listed.
IJob.Execute takes a CancellationToken, IJobFactory hands out a JobScope rather than a bare instance, every public Task became ValueTask, and every asynchronous member ends with a cancellation token.
Job store listings became queries — QueryJobs / QueryTriggers return a PagedResult<T> whose rows already carry what a listing needs, so a dashboard over a large schema no longer pays for the whole schema. The old call shapes remain as extension methods.
A cluster can be read from outside. TriggerState.Executing says whether a trigger's job is running anywhere in the cluster; fire instances, cluster nodes, execution groups, misfires and history are listings that say which node they came from; the health check notices a node whose own check-in has stopped.
Recurrence triggers (RFC 5545 RRULE), an HTTP API with an IScheduler client over it (the replacement for .NET Remoting, which is gone), a dashboard, typed job input (IJob<TInput>; UsingInput(input) on a registration, ScheduleJob<TJob, TInput>(input, at) for a one-off), a retry policy a trigger carries — persisted, cluster-safe, never burning a repeat count — job execution middleware, a [JobTimeout] attribute, execution groups with per-node or cluster-wide limits, node affinity, and a firing that links back to the trace that scheduled it.
Joining a transaction the application owns — the ADO job store can enlist in a transaction you started, so saving your data and scheduling the job that acts on it commit together or not at all.
Cron says what it means. A wildcard day field no longer swallows the other day field's restriction (0 15 10 1 * * is the 1st, not every day); a time the clocks skip fires when the gap ends; the parser refuses what it used to quietly reinterpret (1-5W, L-3 in day-of-week, MON,FRI#3, MON/2, steps of zero); the five-field Unix form and the @daily-style macros work everywhere an expression is read.
Daylight saving fire times changed. Interval cron expressions fire through both halves of a repeated fall-back hour; CalendarIntervalTrigger with PreserveHourOfDayAcrossDaylightSavings steps in local wall-clock time and no longer drifts in zones whose delta is not a whole hour; calendars mean the local day even where midnight itself moves. Review any schedule that crosses a transition.
Quartz.Aspire: builder.AddQuartzPersistentStore("quartz") turns an Aspire connection name into a configured persistent store with its telemetry and health check, with no Aspire.* dependency; a store can provision its own schema as it starts (ProvisionSchema()), safe under a cluster racing to start.
Safe by default. MapQuartzHttpApi() and MapQuartzDashboard() refuse to start unless the endpoints carry authorization or an explicit AllowAnonymous(); a scheduler can be authorized on its own name, and every call the dashboard makes is authorized where it is made.
Observability that a backend can subscribe to by name. ActivitySource("Quartz") and Meter("Quartz") (the names are public constants), nine instruments, spans on every store the same way, and every log line carrying a stable event id — 278 of them, catalogued on a generated page.
Trimming and native AOT are something CI runs. Quartz declares IsAotCompatible; a canary is published natively and run against a real store on three operating systems on every pull request; the remaining string-named paths are recorded and each has a documented alternative (#3341).
Faster per firing than 3.20 on both stores — 1.5× faster and 2.4× less allocation on PostgreSQL, faster and 21 % less allocation on RAMJobStore (numbers below).
Every public member is documented and the compiler holds it there; every collaborator is handed a context object; any member added to a public interface in 4.x arrives as a default interface member. The seams are registered in Extending Quartz.
A much smaller public surface — the scheduler core, the ADO SQL and JobRunShell are internal, and non-public types are sealed. If something you relied on is gone, say so in an issue; these can be reopened.

Breaking changes, the ten to know before the guide

net10.0 only.
Quartz.Extensions.DependencyInjection, Quartz.Extensions.Hosting and Quartz.Serialization.SystemTextJson are part of Quartz; Quartz.Serialization.Json is Quartz.Serialization.Newtonsoft; Quartz.OpenTracing has no 4.x release, and OpenTelemetry.Instrumentation.Quartz produces nothing on 4.x — subscribe to the source and meter directly. The first error a mixed project produces is CS0433 (a type in both Quartz 4 and a 3.x satellite): remove the three references.
StdSchedulerFactory, DirectSchedulerFactory and quartz.config are gone; AddQuartz(…) or QuartzSchedulerBuilder.Create(q => …) build a scheduler.
Task → ValueTask on nearly every member, and a CancellationToken on every asynchronous one.
Quartz.Spi is Quartz.Extensibility, Quartz.Simpl merged into Quartz.Impl, the Newtonsoft types left the core namespaces. A string naming an old namespace still resolves, with a warning.
Every listener callback is told which scheduler is calling; the three *Support base classes are gone (every member has a default body); a listener with a 3.x signature is refused at registration.
Misfire instructions are per-family enums; TimeOnly and DateOnly replace TimeOfDay; TimeProvider replaces SystemTime; the semaphores are lock handlers.
The cron rules above — audit stored expressions with the guide's query before upgrading; a newly refused form fails at load, loudly. The reverse is quiet: an expression from another six-field dialect that 3.x refused (no ? in either day field) now parses, and two shapes fire on a different day than Cronos would — a bare digit in day-of-week (Quartz numbers Sunday 1) and both day fields restricted (Quartz fires on the union). The guide's second audit finds them.
The schema: columns that were optional on 3.x are required, the acquisition index is reshaped, one index is dropped, one table is added. The upgrade script runs while 3.x nodes are up; the index script runs once the last one is gone.
The trigger's end time is the last instant at which it may fire, uniformly, and the daylight-saving fire times above.

Everything else — every renamed member, every sealed type, every removed constant — is in the guide, with the name you would have typed.

Fixes worth knowing about

The full list is spread over the six pre-release notes below. These change what a running cluster does without saying so, and most of them are as old as 3.x:

ResumeAll could unpause real trigger groups: it deleted the all-groups sentinel with a LIKE, and the sentinel's four underscores are wildcards.
... (truncated)

4.0.0-rc.2

The second release candidate. rc.1 was put to the test it was made for — a real application, on 3.19.1 in production, upgraded by the guide — and that upgrade found three things the pre-release gates had not. They are fixed here, and 4.0.0 is this commit once the same upgrade is repeated against it and comes back clean.

dotnet add package Quartz --version 4.0.0-rc.2

Changed since rc.1

A process that cannot load the job classes can edit their schedules (#3705). The persistent store's RescheduleJob and UpdateTriggerDetails resolved the job's class in order to decide whether the new trigger could run, and failed in a process without the assembly — the ZeroSizeThreadPool administration node, a web application that edits schedules the worker runs. Both now read the job's two attribute flags from QRTZ_JOB_DETAILS.IS_NONCONCURRENT and IS_UPDATE_DATA, as every other read already did, and the decision is right without the class: a trigger stored for a [DisallowConcurrentExecution] job that is executing is BLOCKED, not WAITING. Such a process needs no ITypeLoader of its own and no placeholder type; every administration operation — read, query, pause, resume, reschedule, update, trigger, add a trigger, edit job data, delete — is pinned by a test that runs a worker and an administration node over one store with the class visible only to the worker. Only the firing path resolves a job's class.
Stopping the host twice at once stops the schedulers once (#3701). host.StopAsync() while host.RunAsync() is pending makes the generic host stop every hosted service twice concurrently; QuartzHostedService enumerated a list the other stop was clearing and RunAsync threw InvalidOperationException: Collection was modified six runs in eight. There is now one stop, and a second caller joins it.
An expression written for another six-field cron library (#3706) — documented, nothing changed in the parser. 3.x refused an expression with both day fields restricted; 4.0 stores it and fires on the union, which is crontab's rule, and a bare numeric day-of-week names a different day here (1-7 from Sunday) than in Cronos or NCrontab (0-6 from Sunday). Cron expressions states the two divergences; the migration guide's second audit is a compiled sample that lists the stored expressions worth reading again.
The SQLite tutorial's restart check is true of its listing (#3702): the sample sets IgnoreDuplicates, without which every restart re-declared the trigger and scheduled it afresh.
The operations page carries the SQL Server soak run on the rc.1 commit (#3703); the docs toolchain's lock file takes the qs and fast-uri advisories (#3704).

Public API: unchanged from rc.1 — the baselines did not move. Schema: unchanged. Nothing in the packages' dependencies changed.

If you ran rc.1

Nothing to run. The schema and the configuration are rc.1's. If you had written a placeholder-type ITypeLoader for an administration node, delete it: it was always a hazard, because whether the placeholder carried [DisallowConcurrentExecution] decided how a replacement trigger was stored for a job it was standing in for.

If you ran an earlier pre-release

The migration guide's appendix If you ran a 4.0 pre-release lists every change between one build and the next, with the section that explains each; the rc.1 notes carry the "If you ran beta.1" list.

What stands behind this build

Everything rc.1's notes describe — the fresh-user journeys against the published packages, the security review, the stable-version pack, the rolling upgrade of a running 3.20 cluster on PostgreSQL and SQL Server, the clustered soaks on both — plus the published-rc.1 check, which built the six documented journeys from the published pages and verified every "If you ran beta.1" item against a beta.1-provisioned schema. The three findings above came from outside those gates: a production application, upgraded by the guide. That is the test 4.0.0 waits for.

Full changes: quartznet/quartznet@v4.0.0-rc.1...v4.0.0-rc.2

4.0.0-rc.1

Quartz.NET 4.0.0-rc.1 — the packages are on NuGet.
Beta.1 made the API a promise. This is the release candidate: 4.0.0 is this commit, tagged as soon
as the remaining hand-run gates are green and no later than a week from now. What changed between the
two is below; what will change between this and 4.0.0 is nothing but the release notes and the site.

The gates this build passed are the ones release day depends on, run against the published beta.1
packages and the documented pages rather than the tree: a developer building every documented journey
from scratch, every example project started, a security review of the HTTP API, the dashboard and the
client, a stable-version pack (this repository had never produced one), the 3.20 → 4.0 upgrade of a
running cluster through its mixed-version window by hand, and a clustered soak. They found things.
Every one is fixed here or named below.

Changed since beta.1

One security fix. With QuartzDashboardOptions.SchedulerAuthorizationPolicy configured — the
multi-tenant deployment that option exists for — a dashboard visitor authorized for one scheduler could
read another's job listing by switching the scheduler picker: the picker took the browser's value on
trust, pages already on screen re-read for it on a synchronous event, and the frame's access check
lagged behind on an asynchronous one. Both halves are closed: the picker refuses a name the filtered
listing did not carry, and every call through the dashboard's own IQuartzApiClient is authorized
before the scheduler is looked up, where ReadOnly was already enforced. The same review found no
hole an unauthenticated caller can reach; its "verified not an issue" list is on the pull request.

A job type named over the wire is a name, on both sides. Beta.1's contract types said a job type
that arrived in a request was stored unresolved and never probed; JobBuilder.Build() resolved it
anyway, on the request thread, and a test that claimed otherwise could not tell. Now: neither side
resolves a name while converting a DTO; the two attribute flags are optional on the wire — an omitted
concurrentExecutionDisallowed used to override [DisallowConcurrentExecution] on the real type with
false — a job whose type resolves nowhere reads as 200 with the flags absent instead of a permanent
500, a client can schedule a job whose type only the server has, a hostile server can no longer
choose an assembly name a client's runtime goes looking for, and a name is checked against IJob
before anything constructs it — a caller-named type used to have its static constructor, module
initializer and instance constructor run, with the scheduler scope's services injected, before the cast
refused it.

Scheduling.IgnoreDuplicates = true on its own works. On beta.1 it was a startup error, because
OverwriteExistingData defaults to true and the validator refused the pair — the one-liner the guide
itself recommended, and the one this repository's own Worker and ASP.NET Core examples wrote, so neither
example started. The default is a default rather than a statement now: setting IgnoreDuplicates turns
overwriting off, and only writing both down is refused. The XML and JSON scheduling files follow the
same rule.

SendMailJob sends a container credential only to a host the container vouched for. The documented
mitigation — keep the SMTP password out of job data, register an ICredentialsByHost — handed a bare
NetworkCredential to whatever smtp_host the job data named, as base64 AUTH LOGIN, to whoever can
schedule the job. A host-agnostic credential with a job-data host is refused, with the message naming
CredentialCache and the host to bind it to; a bound cache answers for its host and nothing else.
smtp_enable_ssl is new and off by default, which is SmtpClient's own default.

The shipped jobs look only where an application put something. DirectoryScanJob found its
... (truncated)

4.0.0-beta.1

Quartz.NET 4.0.0-beta.1 — the packages are on NuGet.
Alpha.1 was the API becoming complete, alpha.2 the API being used, alpha.3 the release where Quartz is
operated, alpha.4 where it is integrated, alpha.5 where the API is finished. Beta.1 is the release where
the API is a promise: every public member has been read against the code it describes, every
documented behaviour has a test or a named caveat, the upgrade from 3.20 has been rehearsed on data a
released 3.20 wrote, and the operational defaults are safe rather than merely documented. It is the first
4.0 build we ask you to run in production — with the caveats list at the end of this page in hand.

Nobody outside this repository has run 4.0 in production yet: the five alphas total a few hundred
downloads and no external issue. Beta.1's validation is our own, which is why it is a beta. The API is
frozen from here to 4.0 — additive changes only, and any member added to a public interface arrives as a
default interface member. The schema is frozen once the 4.0 script has run. Stored blobs and the wire
format are frozen.

Changed since alpha.5

Six statements the frozen surface made were not true, and were corrected rather than documented around.
Each has a migration-guide row under Between the alphas and beta.1; coming from 3.x, read them as part
of 4.0.

MapQuartzHttpApi() and MapQuartzDashboard() refuse to start when nothing authorizes them. An
alpha application that mapped either bare gets an InvalidOperationException at startup naming the three
fixes: RequireAuthorization() on the returned builder, the options' authorization policy, or an explicit
AllowAnonymous(). Both surfaces schedule a job whose type is a string from the request; with
Quartz.Jobs on the path that is remote code execution, and an open endpoint is no longer the default.
MapQuartzDashboard() returns an IEndpointConventionBuilder covering the pages and the SignalR
hub, so one RequireAuthorization() is the whole answer; the old return type protected the pages alone.
IScheduler's mutation members raise ArgumentNullException for a null argument, as the extension
methods on the same type always did; SchedulerException("… cannot be null") is gone.
CronExpression.TryParse(s, format, out) answers false for a CronFormat it does not know rather
than throwing out of a Try; the constructor and Parse agree on ArgumentNullException.
Two annotations tell the truth: TriggerBase.FireInstanceId / IOperableTrigger.FireInstanceId and
DbMetadata.ParameterDbTypePropertyName are string?.
A paged HTTP request is bounded by QuartzHttpApiOptions.MaxPageSize (1000), and a 500 no longer
carries the exception's message unless IncludeStackTraceInProblemDetails is on.

Three more corrections change what a running program does without changing a shape: Quartz:Scheduling
refuses IgnoreDuplicates while OverwriteExistingData is on (the pair was silently inert); a
job-data string written with a decimal comma ("3,14") is unreadable by every numeric accessor instead
of reading as 314 from the floating-point ones; and a persistent store refuses a repeat interval finer
than a millisecond instead of storing it as zero and wedging the trigger (#3673).

The upgrade is rehearsed

A console project on the released Quartz 3.20.0 packages seeds a database with every persisted
trigger family, blob-stored triggers, all six calendar kinds, a job data map of every admitted value type,
paused trigger and job groups with members added after the pause, and a firing abandoned by killing the
process; the 4.0 script runs over it; a 4.0 scheduler starts and checks every row against the manifest,
recovers the abandoned firing and fires everything. On every dialect, on every pull request. The blobs it
captured are now the unit fixtures the serializers are held to.
... (truncated)

4.0.0-alpha.5

Quartz.NET 4.0.0-alpha.5 — the packages are on NuGet. Alpha.1 was the API becoming
complete, alpha.2 the API being used, alpha.3 the release where Quartz is operated, alpha.4 where
it is integrated; alpha.5 is the release where the API is finished. This is the last alpha:
breaking changes end here, and what ships now is the shape 4.0 keeps.

Cron says what it means

The whole cron surface was put against Vixie cron and Cronos, and every place where Quartz silently
did something other than what the expression said is gone:

A wildcard day field no longer swallows the other day field's restriction. 0 15 10 1 * * —
the natural Unix spelling of "the 1st at 10:15" — used to fire every day of the month; it now
fires on the 1st. A field written * or ? restricts nothing (the two are now full synonyms
there); when both day fields name days, the union fires — the crontab(5) rule, kept deliberately
where Cronos would AND.
A time the clocks skip fires when the gap ends — and IsSatisfiedBy agrees it fired, which the
old delta-shift could never manage. Fall-back behavior is unchanged from alpha.4's Cronos-aligned
rules.
The parser refuses what it used to quietly reinterpret: 1-5W (the W was dropped), L-3 in
day-of-week (meant "Saturday"), MON,FRI#3 (the Friday was ignored), 'C' (never implemented),
steps of zero, and MON/2 — whose "every second week" had no stable phase and re-anchored on every
misfire, restart and failover. Fortnights belong to RecurrenceScheduleBuilder; the migration
guide carries a pre-upgrade audit query for stored expressions.
A cron expression can be written in the Unix five-field form: CronExpression.Parse("30 4 * * 1", CronFormat.Unix) — day-of-week numbered 0–7 the crontab way, normalized to the canonical Quartz
form. And the @ macros (@daily, @hourly, @weekly, …) work everywhere an expression
string is read — code, JSON and XML files, the dashboard, the HTTP API — with no opt-in, including
through the hash-resolving paths.
The surface slimmed to match: Parse/TryParse/ParseWithHash/TryParseWithHash replace four
validator members and two constructors that made new CronExpression(expr, null) ambiguous;
GetTimeBefore is now GetPreviousValidTimeBefore; GetExpressionSummary's internal-state dump
is gone.

A job's timeout is middleware

JobInterruptMonitorPlugin's stringly "AutoInterruptable"/"MaxRunTime" keys are retired. A
timeout is now AddJobTimeout(TimeSpan) with a per-job [JobTimeout("00:05:00")] attribute; on
expiry the firing's own cancellation token fires through the standard interrupt path, and the
timeout reports as a retryable failure your RetryPolicy sees.

The listener surface earns its place

IListenerManager drops its eight runtime matcher-mutation members (matchers are settled at
registration, and the notify path got faster for it); the three Broadcast* listeners are gone (the
manager already fans out); TriggerMisfired leads with its trigger like every sibling.

Acquisition reads at the speed of its index

IDX_QRTZ_T_NFT_ST now carries PRIORITY DESC, MISFIRE_INSTR: a 100k-trigger acquisition round
trip drops from 21.6 ms to 589 µs on SQL Server (20,395 → 8 reads), with MySQL and Postgres wins to
... (truncated)

4.0.0-alpha.4

Quartz.NET 4.0.0-alpha.4

Alpha 4 is the integrator release: a framework that embeds Quartz — a message bus scheduling deferred
messages, a workflow engine firing timeouts, an application framework running background work — now
gets an integration surface designed for it rather than assembled from the app-facing API. The proof
is in this repository: MassTransit's Quartz integration, ported onto these primitives, lost 87 lines
and two whole classes, replaced three store round trips per upsert with one atomic call, and swapped
sixteen stringly-typed JobDataMap keys for one typed payload. A runnable Wolverine reference example
ships in the repo (src/Quartz.Examples.Wolverine).

Typed job input

IJob<TInput> — a job that takes a deserialized, typed payload; the input rides the trigger as a
single reserved string entry, survives every store and serializer, and is read back by static type
(#3521, #3540).
scheduler.ScheduleJob<TJob, TInput>(input, at | delay, options) — the one-liner: one durable job
per TJob, one trigger per call, the trigger group as the correlation axis (#3522).
IJobInputSerializer extensibility point; the default is System.Text.Json with the same
type-info-resolver registry the store serializer uses, so native AOT keeps working (#3540).

Scheduling as an integrator needs it

Atomic upsert: ScheduleJob(trigger, ScheduleJobOptions) replaces the
Exists → Unschedule → Schedule dance with one store operation under one lock (#3522).
Cancel by correlation: DeleteJobs(GroupMatcher<JobKey>) and
UnscheduleJobs(GroupMatcher<TriggerKey>) return the removed keys; matching HTTP API endpoints
(#3523, #3558).
Deferred start: QuartzHostedServiceOptions.AutoStart = false — the scheduler is built, bound
and visible, and the embedding framework decides when it starts; the health check reports
Degraded, not Unhealthy, while it waits (#3525).
Trace context across the scheduled gap: scheduling inside an Activity records the W3C trace
context on the trigger; the firing's span links back to it — an ActivityLink, not a week-long
parent. On by default, QuartzSchedulerOptions.PropagateTraceContext opts out (#3524, #3565).

Job execution middleware

IJobExecutionMiddleware wraps the execute call itself — something a listener structurally cannot do:
open a scope around the job, translate exceptions, short-circuit. Registered per scheduler with
AddJobMiddleware<T>(), ordered, zero overhead when none are registered (#3526, #3553).

Retry policy

Triggers carry a first-class retry policy: TriggerBuilder.WithRetryPolicy(RetryPolicy.Exponential(5, TimeSpan.FromSeconds(30))) re-fires a failed job on its own schedule — persisted, cluster-safe,
survives failover mid-wait and mid-execution, never burns a repeat count or an RRULE COUNT slot,
and yields to the next scheduled occurrence rather than double-firing. Exhaustion returns the trigger
to its ordinary schedule: one bad hour must not kill a cron trigger. A 15-case matrix pins the edge
cases on both stores; quartz.trigger.retry joins the meters. RefireImmediately remains what it
always was — an in-process re-execution, not a retry (#3520, #3569).

... (truncated)

4.0.0-alpha.3

Quartz.NET 4.0.0-alpha.3 is the third pre-release of 4.0. Alpha.1 was the API becoming complete; alpha.2
was the API being used. This one is the release where Quartz is operated: a cluster can be read
from outside — its nodes, its execution groups, its misfires, its history and its meters all say which
node they came from; the persistent store is honest about what it stored and about what failed, and it
spends a statement on a set rather than on each of its members; the trimming and native AOT claim
stopped being a compile and became a scheduler that CI publishes natively and runs against a real
database; and the test suite now proves what the documentation had been promising — daylight saving end
to end, misfires through a store, clustering on every engine, and the job-store contract on every
dialect that ships.

This is still an alpha. There is no compatibility promise between pre-releases, and this one moves
several names and changes several behaviours. The
migration guide carries
every change with before and after; the sections named below are its.

There is no schema migration in this release. Nothing under database/migrations/ changed, so a
database created or upgraded for alpha.2 needs nothing done to it. The fresh-install scripts under
database/tables/ did change — all eight can now be told not to drop an existing schema — but those
build a new schema rather than upgrade one.

Before you start

An application written against alpha.2 will not build or start until these seven are dealt with.

A registered job may not take a scheduler's parts by constructor, and startup says so. A job type
the container holds is built by the container, which resolves constructor parameters without a
scheduler's service key — so a job on scheduler acme taking IScheduler, ISchedulerFactory,
IJobStore, IThreadPool or one of a scheduler's options types was handed the default
scheduler's, or could not be built at all in a container holding only named schedulers. Options
validation now refuses it, naming the job, the parameter and the three ways to write it instead
(IJobExecutionContext.Scheduler, IJobExecutionContextAccessor, or AddJobType<T>(provider => …)
resolving the part by key). Every public constructor is examined, not the one the container would
pick, because which one that is depends on what else is registered. TimeProvider and
IServiceProvider are deliberately excluded.
(closes #3388)
The semaphores are lock handlers. A semaphore is a counted permit; what Quartz has is a
mutual-exclusion lock over a named row, one holder, re-entrant ...

Description has been truncated

Bumps dotnet-ef from 10.0.11 to 10.0.12 Bumps MailKit from 4.17.0 to 4.18.0 Bumps Microsoft.AspNetCore.Authentication.JwtBearer from 10.0.11 to 10.0.12 Bumps Microsoft.AspNetCore.DataProtection.EntityFrameworkCore from 10.0.11 to 10.0.12 Bumps Microsoft.AspNetCore.SignalR.Client from 10.0.11 to 10.0.12 Bumps Microsoft.EntityFrameworkCore from 10.0.11 to 10.0.12 Bumps Microsoft.EntityFrameworkCore.Design from 10.0.11 to 10.0.12 Bumps Microsoft.EntityFrameworkCore.Relational from 10.0.11 to 10.0.12 Bumps Microsoft.EntityFrameworkCore.Sqlite from 10.0.11 to 10.0.12 Bumps Microsoft.Extensions.Configuration from 10.0.11 to 10.0.12 Bumps Microsoft.Extensions.Configuration.EnvironmentVariables from 10.0.11 to 10.0.12 Bumps Microsoft.Extensions.Configuration.UserSecrets from 10.0.11 to 10.0.12 Bumps Microsoft.NET.Test.Sdk from 18.9.0 to 18.10.0 Bumps MudBlazor from 9.9.0 to 9.10.0 Bumps Quartz from 3.20.0 to 4.1.0 Bumps Quartz.Extensions.Hosting from 3.20.0 to 4.1.0 Bumps Quartz.Serialization.SystemTextJson from 3.20.0 to 4.1.0 Bumps System.Drawing.Common from 10.0.11 to 10.0.12 Bumps System.Security.Cryptography.Xml from 10.0.11 to 10.0.12 --- updated-dependencies: - dependency-name: dotnet-ef dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: MailKit dependency-version: 4.18.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: dotnet-dependencies - dependency-name: Microsoft.AspNetCore.Authentication.JwtBearer dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.AspNetCore.Authentication.JwtBearer dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.AspNetCore.DataProtection.EntityFrameworkCore dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.EntityFrameworkCore dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.AspNetCore.DataProtection.EntityFrameworkCore dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.EntityFrameworkCore dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.AspNetCore.SignalR.Client dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.EntityFrameworkCore.Design dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.EntityFrameworkCore.Relational dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.EntityFrameworkCore.Design dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.EntityFrameworkCore.Relational dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.EntityFrameworkCore.Sqlite dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.Extensions.Configuration dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.Extensions.Configuration.EnvironmentVariables dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.Extensions.Configuration.UserSecrets dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: Microsoft.NET.Test.Sdk dependency-version: 18.10.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: dotnet-dependencies - dependency-name: Microsoft.NET.Test.Sdk dependency-version: 18.10.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: dotnet-dependencies - dependency-name: MudBlazor dependency-version: 9.10.0 dependency-type: direct:production update-type: version-update:semver-minor dependency-group: dotnet-dependencies - dependency-name: Quartz dependency-version: 4.1.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: dotnet-dependencies - dependency-name: Quartz dependency-version: 4.1.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: dotnet-dependencies - dependency-name: Quartz.Extensions.Hosting dependency-version: 4.1.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: dotnet-dependencies - dependency-name: Quartz.Extensions.Hosting dependency-version: 4.1.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: dotnet-dependencies - dependency-name: Quartz.Serialization.SystemTextJson dependency-version: 4.1.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: dotnet-dependencies - dependency-name: Quartz.Serialization.SystemTextJson dependency-version: 4.1.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: dotnet-dependencies - dependency-name: System.Drawing.Common dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: System.Security.Cryptography.Xml dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: System.Security.Cryptography.Xml dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies - dependency-name: System.Security.Cryptography.Xml dependency-version: 10.0.12 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: dotnet-dependencies ... Signed-off-by: dependabot[bot] <support@github.com>

dependabot · 2026-09-14T01:15:18Z

Labels

The following labels could not be found: dependencies, security. Please create them before Dependabot can add them to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

dependabot Bot mentioned this pull request Sep 14, 2026

deps: Bump Quartz and 2 others #337

Closed

Navigation Menu

deps: Bump the dotnet-dependencies group with 19 updates - #408

deps: Bump the dotnet-dependencies group with 19 updates#408
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/nuget/dot-config/dotnet-dependencies-6c39030b28

dependabot Bot commented on behalf of github Sep 14, 2026

Uh oh!

dependabot Bot commented on behalf of github Sep 14, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

dependabot Bot commented on behalf of github Sep 14, 2026

18.10.0

What's Changed

9.10.0

What's Changed

New Features

Bug Fixes

Accessibility

Performance

4.1.0

Highlights

Public API — additive only

Behaviour changes worth noting

Also

4.0.1

What changed

Upgrading

4.0.0

Highlights

Breaking changes, the ten to know before the guide

Fixes worth knowing about

4.0.0-rc.2

Changed since rc.1

If you ran rc.1

If you ran an earlier pre-release

What stands behind this build

4.0.0-rc.1

Changed since beta.1

4.0.0-beta.1

Changed since alpha.5

The upgrade is rehearsed

4.0.0-alpha.5

Cron says what it means

A job's timeout is middleware

The listener surface earns its place

Acquisition reads at the speed of its index

4.0.0-alpha.4

Quartz.NET 4.0.0-alpha.4

Typed job input

Scheduling as an integrator needs it

Job execution middleware

Retry policy

4.0.0-alpha.3

Before you start

Uh oh!

dependabot Bot commented on behalf of github Sep 14, 2026

Labels

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants