v1.0.4 - 2026-07-22

[1.0.4] - 2026-07-22

Changed

• SHA-pinned every GitHub Action reference across all three workflow files (validate.yml,
  lint.yml, release.yml), including home-assistant/actions/hassfest@master and
  hacs/action@main, which were floating branch refs that Dependabot's github-actions
  ecosystem could never version-bump at all. Both actions' release tags are years stale
  (hassfest: 1.0.0 from 2020; hacs/action: 22.5.0 from 2022), so both are pinned to their
  current default-branch HEAD commit instead, with an inline comment documenting the pin date
  and reason. Also bumped astral-sh/ruff-action (v3 → v4.1.0) and astral-sh/setup-uv
  (already SHA-pinned, but to a stale v8.3.2 → v9.0.0) to their current major releases, and
  SHA-pinned actions/checkout and softprops/action-gh-release to their current tags.
  Resolves #72.
• Removed the requires-python = "...,<3.15" and josepy<3.0.0 upper-bound constraints from
  pyproject.toml. Verified empirically that removing the Python ceiling doesn't reintroduce
  the resolution forking this project has fought before — no package in the dependency tree
  publishes anything Python-3.15-specific yet, so uv lock still resolves to a single,
  unforked graph. The josepy ceiling was already redundant: hass-nabucasa (pulled in by
  homeassistant) declares its own josepy<3,>=2 constraint, so removing our copy avoids
  needing to remember to raise it later.
• Moved the devcontainer's .venv off the bind-mounted workspace folder (which is bridged from
  the Windows host via 9p, a filesystem protocol poorly suited to many-small-file workloads)
  onto the container's own native filesystem (/home/dev/.venv), matching the pattern in
  home-assistant/core's own Dockerfile.dev. A uv sync that previously took over 22 minutes
  now completes in seconds.

---

[1.0.3] - 2026-07-22

Added

• Diagnostics now include a capped sample of actual offer data alongside the existing
  offer_counts_by_platform: sample_offers (flat, first 10 across all platforms) and
  sample_offers_by_platform (first 3 per platform, guarding against the flat list starving out
  a platform whose feed happens to iterate after others with more offers). Every GameOffer
  field is public promotional metadata from the feed — reviewed field-by-field, nothing
  personally identifiable, so no redaction was needed (documented inline in diagnostics.py).
  Added a json.dumps(result) regression test to catch a non-serialisable value before it could
  reach a user's downloaded diagnostics file. Resolves #71.

v1.0.2 - 2026-07-21

[1.0.2] - 2026-07-21

Changed

• Bumped the devcontainer's base image from mcr.microsoft.com/devcontainers/python:3.13 to :3.14, and
  requires-python from >=3.13.2,<3.14 to >=3.14.2,<3.15 (.python-version from 3.13 to 3.14),
  to track current homeassistant (2026.7.2, up from 2026.2.3) and
  pytest-homeassistant-custom-component (0.13.346). Verified with a real uv lock/uv sync/pytest
  run (single resolution, no pymicro-vad/pyspeex-noise, 148 passed, 100% coverage) plus ty check and
  ruff — no breakage from the version jump.
• Raised the minimum supported Home Assistant version declared in hacs.json and the README's Requirements
  section from 2024.6.0 to 2026.7.2, matching what the dev/test harness now actually verifies — the old
  floor was carried forward from before this project had any test coverage against it, and there's no
  ongoing verification that anything between 2024.6.0 and 2026.7.2 still works.
• Removed test-only workarounds that existed solely for running pytest on native Windows, now that dev/test
  runs exclusively inside the devcontainer (#67): the HassEventLoopPolicy._loop_factory/SelectorEventLoop
  patch and the socket.socketpair() TCP-emulation shim in tests/conftest.py (both gated behind
  sys.platform == "win32", so pure dead code once tests never run on Windows), and the
  mock_client_session fixture in tests/test_config_flow.py (verified empirically that all 19
  test_config_flow.py tests still pass without it — the real network-call protection it was layered on top
  of is already handled by the separate per-test fetch_feed_data mock). homeassistant itself is moving
  the same direction (homeassistant.runner now imports POSIX-only stdlib modules unconditionally — see the
  entry above), so maintaining Windows-specific test scaffolding no longer serves any purpose.

v1.0.1 - 2026-07-21

[1.0.1] - 2026-07-21

Changed

• Upgraded the dev/test dependency chain off the old homeassistant==2024.11.0b7 beta pin
  to homeassistant==2025.2.5 / pytest-homeassistant-custom-component==0.13.215 /
  aiohttp==3.11.12 — the latest stable pairing available before homeassistant started
  unconditionally depending on pymicro-vad/pyspeex-noise, which have no published Windows
  wheels. Raised requires-python to >=3.13,<3.14 to match the new test harness's floor. No
  runtime/functional change to the integration itself.
• Worked around an upstream Windows incompatibility in
  pytest-homeassistant-custom-component's mock_zeroconf_resolver fixture (present in every
  release from 0.13.181 through the latest 0.13.346): it eagerly constructs a real
  aiodns.DNSResolver, which requires a SelectorEventLoop on Windows, but the harness also
  installs homeassistant.runner.HassEventLoopPolicy and neuters
  asyncio.set_event_loop_policy, so the usual pytest-asyncio override has no effect. Patched
  HassEventLoopPolicy._loop_factory directly in tests/conftest.py instead.
• Grouped homeassistant, pytest-homeassistant-custom-component, aiohttp,
  pytest-asyncio, pytest, and josepy in .github/dependabot.yml so future Dependabot
  updates propose one resolvable bump instead of several that each fail independently (#58,
  #55) — pytest-homeassistant-custom-component pins exact versions of the first four, and
  homeassistant transitively requires josepy>=1.13.0,<2 via hass-nabucasa/acme, so
  isolated single-package bumps are structurally unsatisfiable.
• Capped requires-python to <3.14 after a Dependabot run failed resolving a
  python_full_version >= '3.14.2' split: an open-ended floor forces uv lock to also find a
  resolution valid for hypothetical future Python versions, and for 3.14+ that meant jumping to
  homeassistant==2026.2.3 (which reintroduces the pymicro-vad Windows problem and pulls in
  hass-nabucasa==1.12.0's josepy>=2,<3, conflicting with our josepy<2.0.0 pin). Capping
  the floor to the Python version we actually pin (.python-version = 3.13) removes the
  multi-version fork at the root instead of chasing each conflict it produces.
• Added constraint-dependencies = ["homeassistant<2025.4.0"] under [tool.uv] after a
  Dependabot "uv group" bump (#62) crossed the pymicro-vad/pyspeex-noise boundary anyway,
  breaking uv sync on Windows on main — the Dependabot grouping only bundles PRs together,
  it doesn't constrain what the resolver picks. A follow-up single-package security PR (#65,
  targeting a zeroconf mDNS cache-poisoning fix, GHSA-qc2x-6f54-m6h9) then swung the other
  way, resolving an older pytest-homeassistant-custom-component==0.13.195 than our intended
  pin and silently dropping zeroconf from the graph entirely rather than patching it — because
  homeassistant==2025.2.5 pins zeroconf==0.144.1 exactly, that CVE can't be fixed
  independently while under the Windows ceiling; it's dev/test-only exposure, since zeroconf
  isn't a runtime dependency of the shipped integration (manifest.json only requires
  beautifulsoup4/lxml). The explicit ceiling makes future resolutions land back on the
  known-good pin (pytest-homeassistant-custom-component==0.13.215 /
  homeassistant==2025.2.5) deterministically instead of wherever an unconstrained resolver
  happens to swing. Revisit alongside #64.
• Moved local dev/test onto a devcontainer (.devcontainer/) and dropped the homeassistant<2025.4.0
  constraint and requires-python upper-bound history above — both turned out to be about native Windows
  being unable to import homeassistant.runner's unconditional, unguarded fcntl/resource stdlib usage
  (no Windows equivalent, present in every current release), not about the pinned dependency versions
  themselves. pyproject.toml now only pins requires-python to the Python line the devcontainer's base
  image actually provides (>=3.13.2,<3.14) for resolution stability, with no Windows-specific constraint at
  all. Dev/test now tracks current homeassistant (2026.2.3 as of this change) again. Native Windows
  uv sync/pytest is no longer a supported path — see CONTRIBUTING.md.

v1.0.0 - 2026-07-15

[1.0.0] - 2026-07-15

First stable release — semver guarantees begin here. Highlights since 0.1.0: Ubisoft/Fab/Steam
Points platform support, a configurable feed base URL and scan interval, automatic entry
reload on options changes, diagnostics, repair issues, config-flow translations and icon
translations, a reconfigure flow, a Platinum-targeted Home Assistant Quality Scale pass
(including an adversarial re-review that fixed a per-platform availability gap and log spam),
and two new optional entity platforms — a calendar showing offer expiry windows and per-platform
event entities for reliable new-offer notifications. See the entries below for full detail on
every 0.x release. The one breaking change across the 0.x series was in 0.6.0 (the platform
attribute's meaning changed from store name to device platform, with the store name moving to
a new store field).

Added

• A Requirements section in the README documenting the minimum supported Home Assistant
  version (2024.6.0), and documentation for the calendar and new-offer event entities
  (previously undocumented after #27/#28 landed).

Changed

• Replaced the placeholder brand icon/logo assets with real "Free Games - LootScraper"
  branding (light and dark variants).

v0.9.10 - 2026-07-15

[0.9.10] - 2026-07-15

Added

• A new event.free_games_<platform>_new_offer entity is now available per selected
  platform (e.g. event.free_games_steam_games_new_offer), firing a new_offer event
  exactly once per newly-seen offer, with the full offer as event attributes. This replaces
  the fragile offers[0]-templated notification pattern in the README's automation example,
  which could miss offers arriving in the same poll or misfire when the feed reordered
  existing offers without any new one appearing.

v0.9.9 - 2026-07-15

[0.9.9] - 2026-07-15

Added

• A calendar.free_games entity now surfaces offer expiry windows (offer_from/offer_to)
  across all selected platforms, enabling the calendar dashboard card and calendar
  event-start/event-end automation triggers. Offers missing an end date are omitted from the
  calendar (they still appear normally in the existing offers attribute); offers missing a
  start date fall back to the date this integration first saw them.

v0.9.8 - 2026-07-15

[0.9.8] - 2026-07-15

Fixed

• A per-platform sensor now correctly goes unavailable when only that platform's own feed
  fetch fails during per-platform fallback, instead of silently reporting a count of 0
  (indistinguishable from "no free games today"). Found by #23's adversarial re-review of
  the entity-unavailable quality-scale rule.
• The integration no longer logs a full traceback and a fallback warning on every failed
  poll on top of Home Assistant's own once-per-outage/once-on-recovery coordinator logging —
  both are now debug-level, eliminating redundant log spam during a sustained outage. Found
  by #23's adversarial re-review of the log-when-unavailable quality-scale rule.

v0.9.7 - 2026-07-15

[0.9.7] - 2026-07-15

Added

• A dedicated "Reconfigure" flow is now available (alongside the existing "Configure"
  options flow), satisfying Home Assistant's reconfiguration-flow quality-scale rule.
  Both flows edit the same settings (stores to track, feed base URL, scan interval) since
  this integration stores all of its configuration in options rather than splitting
  required connection data from optional settings.

v0.9.6 - 2026-07-14

[0.9.6] - 2026-07-14

Added

• A repair issue is now created when the Free Games feed fails to fetch for 3 consecutive
  polls, appearing in Home Assistant's Settings > System > Repairs. The message differs
  depending on whether base_url is the public default (suggesting a possible temporary
  outage or local network issue) or a custom self-hosted value (suggesting the self-hosted
  instance or the configured URL should be checked). The issue clears automatically on the
  next successful fetch.

v0.9.5 - 2026-07-14

[0.9.5] - 2026-07-14

Added

• A diagnostics platform (diagnostics.py) is now implemented, letting users download
  structured debugging state from Home Assistant's UI: configured options, coordinator
  health (last_update_success, last_exception), and per-platform offer counts (not full
  offer payloads). A custom (self-hosted) base_url is redacted, since it could reveal a
  private network address or hostname; the public default URL is shown in full.