Another Brighter release! As of 10.5.0, we now support exporting AsyncAPI from Brighter-enabled applications that describe your endpoints. Similar to OpenAPI for ASP.NET endpoints, but this is for messaging, not HTTP.
nuget.org/packages/Paramore.…
We have released 10.3.3 or Brighter.
This includes a fix for Kafka commit errors during partition reassignment in 10.3.3. We now check whether an existing flush is running across batch, time, and partition loss triggers (the latter was not previously checked).
We have been using coding agents with @BrighterCommand since last year, a few observations.
- As a project, Brighter supports many transports, out/in boxes, schedulers, storage, and distributed locks to fit into environments where it is to be deployed.
We have released Brighter 10.3.0, which includes a significant upgrade of our error-handling strategies - hence the minor version bump.
Brighter’s default behavior is to ack a message when an error leaves the handler pipeline. The principle here is that errors come in two forms:
Solid advice.
We have a PR in to add Roslyn Analyzers to @BrighterCommand, and I think that will be exceptionally helpful when agents write Brighter code.
The advice to prefer retrieval over training may help: look at @Aaronontheweb's work here
rough thoughts on dotnet (csharp) and agentic
- agentmd should steer towards latest c# style ie “only use .net 10 code style” because of the wide degree of variance over the years. even with that guardrail in place it’s a mixed bag because the language has evolved so much over the years and models have that in their training data.
- migrating a codebase from v8 coding style to v10 coding style super easy to do!
- dotnet null just sucks; discriminated unions - miss eithert/maybe heaps and plenty of scenarios which should have been compiler time validation end up as runtime blowups.
- writing roslyn analysers is now neat, fun and super productive. there’s no excuse to not utilise them to create back pressure
- nuget still sucks; can’t ripgrep a dll and monkey patching libraries still sucks/not really possible/easy to do.
- configuring compiler warnings to max level of aggression helps heaps. warnings should fail builds.
We have just released version 10.1.0 of Brighter. nuget.org/packages/Paramore.…
The minor version bump is due to improvements in the management of resources we create in our factories. Brighter uses a DI-friendly framework approach, which means we implement factories for DI providers
For those of you still on V9 of Brighter, our bug fix release 9.9.13 fixes an issue where the stale offset sweeper was not running and clearing stale offsets. (Fix also in 10.0.3)
We have pushed 10.0.3 of Brighter. Mostly bug fixes, but includes support for TickerQ as a scheduler, and EF integration for the MongoDb Outbox. Thanks to all our existing and new contributors: nuget.org/packages/Paramore.…
We have released V10 of Brighter. This represents a significant set of improvements and sets the groundwork for other changes in V10.X releases to come. (We will continue to support V9 with bug fixes until V11; Our release cadence for major versions is 1-2 years.) Details below.
We've released Brighter **v10 RC2** (`10.0.0-preview.7`). We are close to feature complete on **V10** with this release. We need to fix bugs and be satisfied of quality before we go a final release.
Some feedback on assigning GitHub CoPilot a Brighter issue: github.com/BrighterCommand/B…
You can see it working here: github.com/BrighterCommand/B…
- It got a long way, fast, with a relatively detailed outline of what to do. The code was as required.
It's pattern recognition, rather than reasoning. That does not diminish its value. A lot of coding tasks are "recognise and apply a pattern to the problem".
However, when you start to wander into areas where it needs to reason about what the code is doing, due to reliance on copy and paste, it stumbles. It can't reason about the test failing because the queue is not created; this test just tests the test itself, not the SUT.