chore(release): prepare v0.1.8

[AzulGarza]

Summary

• Bump foundationforecast to v0.1.8 for PyPI/GitHub release
• Finalize changelog notes (PatchTST-FM r2, T0 beta, shared panel processing, FlowState freq fix)
• Add a News table to the README with recent model/checkpoint additions by date

Release highlights (since v0.1.7)

• Granite PatchTST-FM r2 (granite-tsfm>=0.3.9)
• T0 beta (tfc-t0>=0.5.0)
• TiRex-2 zeroshot in gift-eval CI
• Shared panel processing across forecasters
• FlowState pandas frequency alias normalization

Test plan

• CI green on this branch
• Merge and tag v0.1.8 to trigger release workflow
• Verify PyPI publish and GitHub release notes

Made with Cursor

[Copilot]

🟡 Changes recommended

The gift-eval lockfile still records the editable package as version 0.1.7.

Get a fresh assessment by requesting another Copilot review.

Pull request overview

Prepares the v0.1.8 release and documents its key updates.

Changes:

• Bumps package and root lockfile versions to 0.1.8.
• Adds release highlights to the changelog and README News section.

File summaries

File	Description
pyproject.toml	Bumps package version.
uv.lock	Updates root locked package version.
README.md	Adds recent project news.
docs/changelogs/v0.1.8.md	Documents performance and frequency fixes.

Review details

• Files reviewed: 3/4 changed files
• Comments generated: 1
• Review effort level: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[codspeed]

Merging this PR will degrade performance by 18.19%

⚡ 1 improved benchmark
❌ 1 (👁 1) regressed benchmark
✅ 15 untouched benchmarks

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
⚡	WallTime	test_model_forecast[moirai-1.1]	1.5 s	1.3 s	+10.43%
👁	WallTime	test_model_forecast[chronos-bolt]	116 ms	191.4 ms	-39.4%

Tip

Curious why performance improved? Comment @codspeedbot explain why performance improved on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing chore/release-v0.1.8 (ed89251) with main (b0bb897)}

[AzulGarza]

@codspeedbot why this regression? hahah

[codspeed]

@codspeedbot why this regression? hahah

Short answer: this one isn't real. Nothing in the PR can make chronos-bolt slower — it's measurement noise on the walltime job.

What the diff contains

git diff main...HEAD on ed89251 touches 5 files: README.md, docs/changelogs/v0.1.8.md, pyproject.toml (version = "0.1.7" → "0.1.8"), and the two uv.lock files (same version line). Zero runtime Python, zero dependency changes, and CI installs with uv sync --frozen, so base and head ran the exact same code and the exact same wheels.

What the measurements say

• All 13 Simulation benchmarks (core/orchestration/panel) are identical to within 0.1–1% — as expected for an instrumented run with no code change.
• The 4 WallTime model benchmarks moved in both directions in the same run: chronos-bolt +65% (median), timesfm-1 −11%, moirai-1.1 −13%, toto +0.3%. A real regression from a version-string bump would not do that.
• chronos-bolt is inherently noisy: on recent main runs its rounds span ~115 ms → 200 ms with a stdev of ~21–26 ms (≈17% CV). CodSpeed reports the fastest round, so base = 116 ms (median 143 ms). In the head run the whole distribution shifted up (min 191 ms, median 206 ms, max 225 ms, stdev 10 ms) — a sustained host-level slowdown for that job (CPU frequency / noisy neighbour on the macro runner), not per-round jitter and not a code effect.

So: safe to acknowledge and ship v0.1.8.

If you want this to stop happening

test_model_forecast[chronos-bolt] is only ~120 ms of Torch CPU inference on 10 series × 100 points, which is right in the range where thread scheduling dominates the signal. Two cheap fixes:

1. Pin Torch threading in the models job (OMP_NUM_THREADS=1 / torch.set_num_threads(1)) so intra-op parallelism can't vary run to run.
2. Give the benchmark more work (more series or a longer context) so each round is ~1 s+ and per-round overhead stops dominating. Related: moirai-1.1 only got 2 rounds in the head run, which is far too few for a stable comparison — the "+10.43% improvement" on it is equally meaningless.

Happy to open a follow-up PR with either change if you want it — just say the word.

Summary

• Warming up the performance wizard...
• Investigate chronos-bolt regression — Compared base b0bb897 vs head ed89251, inspected per-round walltime distributions and historical runs
• Report findings — Regression attributed to walltime noise on the models job: PR diff contains no runtime code
• Handling comment — Comment handling finished successfully

_{Was this response helpful? React with 👍 or 👎 to help us improve CodSpeedBot.}