Skip to content

Releases: jerbersoft/databentodotnet

v0.10.0 — five packages, and the fifth one's first release

Choose a tag to compare

@jerbersoft jerbersoft released this 01 Sep 23:39

Five packages. DatabentoDotNet.Extensions.Hosting reaches nuget.org for the first time:
IServiceCollection registration for the historical, reference and live clients, IConfiguration
binding, and a live session running as a BackgroundService with bounded reconnection, an opt-in
health check and metrics — allocating nothing per record, the same guarantee the core four carry.

dotnet add package DatabentoDotNet.Extensions.Hosting --version 0.10.0

Start with the hosting guide.
You supply the host: this package references Microsoft.Extensions.Hosting.Abstractions and never
the host itself, so it plugs into your Program.cs rather than bringing one.

Upgrading from 0.9.1

Change the version. Nothing was removed, renamed or retyped in any of the four packages you already
have.

The one change to the core four

HistoricalClient gained Handler and DisposesHandler (#86) — a settable HttpMessageHandler
and a flag saying who disposes it. Four public members, additive.

A singleton HistoricalClient in a host that stays up for weeks keeps talking to whatever
hist.databento.com resolved to on its first request. Reaching it through IHttpClientFactory is
what rotates that, and nothing before this provided a way in.

This is the whole return on the beta. 0.9.0 existed to find out whether the public surface was
the right shape, and designing the hosting package against the library from a consumer's position is
what answered: one gap, filled by addition, nothing withdrawn. Two releases of exposure produced
exactly one change.

Why the fifth package is 0.x and not 1.1.0

ROADMAP.md §8 had reserved it for 1.1.0, because shipping five packages under one SemVer promise
would guarantee this one's surface before anything had built against it. That ground is correct, and
it is why the number moved rather than survived.

0.x carries no promise — so the objection was never about a 0.x release, and none was in
prospect when 1.1.0 was chosen. What the assumption cost was the evidence window itself: under the
1.1.0 plan this package's window was the stretch when it was not installable, usable only from
a project reference. The core four got something categorically better — on the feed, unpromised,
available to anyone. Reserving a worse window for the fifth package, in the name of giving it a
window, was the argument contradicting itself.

Pin the exact version. If something in this package's API is awkward to call,
an issue now is far cheaper than a major
version later. That is what the window is for, and it is the only way it gets spent.

PublicAPI.Shipped.txt stays empty in all five packages. That file records a surface undertaken not
to break, and 0.10.0 undertakes nothing — #68 is where that starts.

Two things caught before they froze

A published package page cannot be edited, only superseded, so both of these would have been
permanent:

  • The extensions package's README said "Ships as 1.1.0, after 1.0." It is the
    PackageReadmeFile, so it would have landed on the page of its own first release announcing that
    the package does not exist yet — #85 repeated exactly. Found by reading the README back out of the
    packed .nupkg rather than off disk.
  • publish.yml was publishing five packages while checking four. dotnet pack has emitted five
    .nupkg since M6, but the push was a nupkg/*.nupkg glob and the PACKAGES list driving both
    the no-op pre-flight and the post-push verification still named four. It happened to be the right
    thing to publish; nobody had decided that. A partition step now fails the run on a packed package
    named by neither PACKAGES nor HELD.

Full narrative: release notes.

Build 0 warnings · 2,043 tests green · Native AOT probe PASS at 278 checks · docs built with
--warningsAsErrors.

v0.9.1 — the package pages, corrected

Choose a tag to compare

@jerbersoft jerbersoft released this 31 Aug 16:49

A documentation patch, and nothing else. The same code as 0.9.0 — if you are not upgrading you
are missing nothing that runs.

dotnet add package DatabentoDotNet.Live --version 0.9.1

Nothing changed, and that is checkable

git diff v0.9.0..v0.9.1 -- 'src/**/*.cs' contains no non-comment line, and all four
PublicAPI.Unshipped.txt are byte-identical to v0.9.0. The 3,801-member surface is exactly where
it was, so the versioning policy is untouched and #68 still owns 0.x → 1.0.0.

So why publish at all

Because two things reach you only from inside a package, and a published package cannot be edited.

The package pages linked to a wiki that no longer exists. #82 moved the guides onto the
documentation site and retired the wiki, correcting every source file in the same commit — but
0.9.0 had already been packed, and nuspec metadata is frozen at pack time. All four 0.9.0 pages
on nuget.org carried four wiki URLs each with no way to correct them in place. The 0.9.1 pages link
to https://jerbersoft.github.io/databentodotnet/ instead.

Those 0.9.0 links are degraded rather than dead — with the wiki disabled GitHub redirects every
/wiki/* path to the repository home page — which is why this is a patch release and not a hotfix.

The XML documentation gained worked examples. #78 added <example> blocks across all four
packages. Those ship inside the .xml in the .nupkg, which is what your editor reads, so on
0.9.0 they reached the API reference on the site and not IntelliSense at the call site.

"Project website" now opens the documentation site

PackageProjectUrl was the GitHub repository; it is now the site. "Source repository" beside it is
unchanged, so nothing is lost from the page. This reverses a decision recorded on #68 — the full
reasoning, including the durability argument that survives and why it is overridden anyway, is in
Directory.Build.props and in the release notes.

Upgrading

Change the version. There is nothing else to do.

<PackageReference Include="DatabentoDotNet.Live" Version="[0.9.1]" />

Still pinned exactly, and still for the reason 0.9.0 gave: this is a beta and the public API can
change before 1.0.


Full narrative: https://jerbersoft.github.io/databentodotnet/release-notes.html

v0.9.0 — Milestones 0-4 Complete

Choose a tag to compare

@jerbersoft jerbersoft released this 30 Aug 09:03

🎯 Release Summary

Milestones 0–4 complete. The DBN codec, real-time live streaming, historical market data, and reference data are fully implemented and tested at 1,841 assertions across the vendored corpus. M5 (polish and 1.0) is in progress.

✅ What's New

M0: Foundation

  • ✅ NodaTime for all date/time handling (nanosecond precision, BCL ban enforced)
  • ✅ Deterministic builds with Source Link
  • ✅ Native AOT trim- and AOT-analysis enabled
  • ✅ Public API analysis (RS0016/RS0017) with PublicAPI baselines

M1: DBN Codec

  • ✅ Zero-copy record decoding over pooled buffers
  • RecordRef — a ref struct valid until the next decoder call
  • ✅ Zstandard (zstd) decompression via ZstdSharp.Port (pure managed, no P/Invoke)
  • ✅ 71 fixture files from databento/dbn 0.68.0 — decoder asserts exact record counts
  • ✅ Symbol maps, metadata decoding, and instrument records

M2: Live Streaming

  • ✅ Real-time TCP gateway client (LiveClient)
  • ✅ Session management and subscription lifecycle
  • ✅ Zero-allocation steady state (GC measured continuously)
  • MockLiveGateway ported from databento-rs — most live tests run against it
  • ✅ Latency measurement and statistics collection

M3: Historical Market Data

  • ✅ HTTPS/REST client (HistoricalClient)
  • ✅ Timeseries, metadata, and batch APIs
  • ✅ Pricing API (get_cost) before pulling data
  • ✅ Symbol resolution and dataset discovery
  • MockHistoricalGateway for testing endpoints

M4: Reference Data

  • ✅ Security master, corporate actions, and adjustment factors
  • ✅ Full reference data API surface

📦 Packages

All packages target net10.0 only. Install with:

dotnet add package DatabentoDotNet.Dbn
dotnet add package DatabentoDotNet.Live
dotnet add package DatabentoDotNet.Historical
dotnet add package DatabentoDotNet.Reference

Available on nuget.org

🛠️ Quality Assurance

  • 1,841 assertions across the project
  • 71 fixture files (0.68.0 Databento corpus) — decoder validates record counts
  • Zero-allocation steady state — GC measurements on live and historical paths
  • Native AOT verified — publishes and runs a binary on every push
  • Zero warnings in Release build
  • TreatWarningsAsErrors enabled
  • Public API enforcement — RS0016/RS0017 via PublicApiAnalyzers
  • ✅ Tests on Linux, macOS, and Windows

📚 Documentation & Resources

  • GitHub Wiki — Guides, explanations, troubleshooting
  • ROADMAP.md — Architecture and design decisions
  • PORTING.md — Rust→.NET mapping for the port
  • API Reference — XML doc comments ship inside each .nupkg (IntelliSense at call site)
  • Samples — Four runnable programs under samples/

🚀 Next: M5 → 1.0.0

M5 (polish phase) is in progress. Tasks include:

  • Package README files
  • Performance tuning and optimization passes
  • Extended documentation and examples
  • Final API review and lock for 1.0.0

🎖️ Acknowledgments

This is a port of Databento's official Rust client and reference implementations in C++ and the DBN codec. Struct layouts are validated against upstream static_assert values.

DatabentoDotNet 0.1.0-alpha.1

Pre-release

Choose a tag to compare

@jerbersoft jerbersoft released this 29 Aug 22:27

First alpha release with DBN codec, Live streaming, Historical data API, and Reference data support.

What's New

  • Zero-copy DBN record decoding
  • Real-time TCP streaming client
  • Historical HTTPS market data API
  • Security master & corporate actions
  • Full Native AOT support