prophet

Use to build Linux wheels. We were pinned to manylinux2014, but the latest versions of scientific computing libs (numpy, etc.) now require newer glibc. This upgrade also requires auditwheel>=6.8.0 to fix binary linking issues in the wheel: https://github.com/pypa/auditwheel/issues/716 Other small cleanups: re-render static API docs with correct version, update wheel.yml versions Successful dev run: https://github.com/facebook/prophet/actions/runs/31860984955

Observation When fitting Prophet with on exactly 12 monthly observations, I observed that the model becomes under-identified (expected). As a result, different Prophet / cmdstanpy versions can converge to very different trend-seasonality decompositions, even when the code and data are identical. In my case, one environment extrapolates reasonable future values, while another produces very large negative forecasts, despite all training observations being strictly positive. Inspecting the model components shows that these differences arise from how trend and yearly seasonality trade off under this configuration. At the moment, there is no warning or safeguard when enabling yearly seasonality with only a single annual cycle of data, which can lead to unstable and version-dependent forecasts in production settings. Environment Azure ML Studio: prophet: 1.1.4 cmdstanpy: 1.2.5 Local (VSCode): prophet: 1.2.1 cmdstanpy: 1.3.0 Minimal reproducible example Observed behavior Azure (prophet 1.1.4) Trend becomes large negative, forecasts become large negative (e.g., -10M to -12M) Local (prophet 1.2.1) Same observation for other future months. Question / Request Could anyone share best practices to handle this case? Is it possible to add a warning or safeguard when enabling yearly seasonality with only a single annual cycle of data?