Merge pull request #22 from CaffeinatedCoder/docs/8.0.0-changelog-note

docs: record the 8.0.0 documentation corrections, and correct the last copy of the claim

7.0.0

6.3.0

6.2.1 — IsAdjacentTo symmetry fix

v6.2.0

Two behaviour changes from the value-semantics audit:

- A null range now reads back as null instead of throwing. The package
  could not read a document it had just written.
- Count over a union reached through Remove counted shared elements
  twice; it is now refused rather than answered.

Every package additionally gains symbols, Source Link and deterministic
builds. The core and EF packages ship their own package READMEs.

chore: release 6.1.0

Minor rather than patch: ElementJsonConverter, RangeVariantJsonConverter
and AddNodaTimeRangeConverters are new public API. Minor rather than
major: nothing that previously worked changes, and the new interface
member is a defaulted virtual static on an interface closed to external
implementation by its internal abstract static FromTrusted, so no
implementer can collide with it.

The release note leads with the one visible payload change — value set
elements that carry no converter of their own now serialize as their text
form instead of as an object — since a consumer who persisted or published
the old shape needs to see it before upgrading. The old shape either
disagreed with what the same value looks like in PostgreSQL or destroyed
data on read, so it is documented as a fix rather than held for a major.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs: cover the v6 value set types in both NodaTime package READMEs

Both NodaTime packages ship their own README as `PackageReadmeFile`, so these
are the nuget.org landing pages rather than internal docs — and both still
described only the v5 range types. The headline v6 feature was invisible to
anyone browsing either package.

CodoMetis.ValueRanges.NodaTime: splits the type listing into ranges and value
sets, adds the five set types with their PostgreSQL equivalents, extends the
example, and documents that the ISO calendar rule now applies at every entry
point rather than only in `From` — `Contains`/`Add`/`Remove` take a bare
element, and `LocalDate.Equals` being calendar-sensitive is exactly why that
matters.

CodoMetis.ValueRanges.EFCore.PostgreSQL.NodaTime: adds the array column
mappings, the translated set algebra, and three notes that only apply here —
calendar normalization of a bare operand bound as a parameter, `YearMonthSet`
persisting first-of-month dates with alignment validated on read, and `Union`
being the one set operation whose SQL result is not canonical.

Also corrects a claim that had gone stale: the `LocalTime` paragraph said a
`LocalTimeRange` twin "may follow if there is demand", written when no
LocalTime-based type existed. `LocalTimeSet` shipped in v6, so the paragraph
now separates the two cases and names the actual reason for the asymmetry —
`time[]` is a built-in array type, `timerange` needs `CREATE TYPE`.

Column types verified against the registrations and the model-mapping tests;
both READMEs confirmed present and current inside the built .nupkg files.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs: expand README with column-driven YearMonthRange construction gu…

…idance

feat: add NodaTime satellite packages (v4.1.0)

Two new packages bring the range model to NodaTime-based projects:

- CodoMetis.ValueRanges.NodaTime: LocalDateRange (daterange),
  LocalDateTimeRange (tsrange) and InstantRange (tstzrange) — the three
  NodaTime primitives with a total order and a built-in PostgreSQL range
  domain. Same five-variant discriminated unions; the generic algebra,
  RangeSet, literals and JSON support apply unchanged. LocalDate/
  LocalDateTime bounds normalize to the ISO calendar at construction;
  text I/O uses culture-free ISO patterns with PostgreSQL wire-form
  parse fallbacks. Includes Interval/DateInterval interop adapters and
  per-type RangeAgg/RangeIntersectAgg overloads.

- CodoMetis.ValueRanges.EFCore.PostgreSQL.NodaTime: maps the three types
  (and their RangeSet counterparts) to PostgreSQL columns through
  NpgsqlRange<T> via Npgsql.EntityFrameworkCore.PostgreSQL.NodaTime.
  UseValueRangesNodaTime() implies UseNodaTime() and UseValueRanges();
  BCL and NodaTime ranges coexist in one model.

To support satellites, the EF plugin's RangeTypeRegistry is now additive:
process-wide immutable-snapshot registry with idempotent Register and
RegisterAggregateExtensions; store-type-name lookups keep first-wins
(BCL) ownership, CLR-type lookups disambiguate the shared column types.

ZonedDateTime/OffsetDateTime are excluded by design: NodaTime gives them
no default ordering, so the IComparable<T> constraint rejects them at
compile time — the double/NaN argument, enforced by the type system.

Tests: 78 satellite unit tests, 31 EF translation tests, and live-
PostgreSQL integration coverage incl. infinity mapping, sub-microsecond
precision pinning, and discrete upper-bound parity. 560 tests green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

v4.0.0 — complete PostgreSQL range/multirange feature matrix