Hydra 1.2 -

Version 1.2 introduces for certain resolver functions. Early benchmarks show a 40% reduction in instantiation time for large config suites. 5. Deprecation of hydra.main This is the breaking change you need to watch for. The decorator @hydra.main() has been a staple since day one. It now throws a DeprecationWarning . In Hydra 2.0 (planned for Q3 2026), it will be removed.

defaults: - storage: aws - optional region: ${storage.region} Hydra was notorious for adding 200–400ms to script startup time because it parsed every @dataclass and OmegaConf structure recursively. For long-running training jobs, this didn't matter. For serverless functions or CLIs? It hurt. hydra 1.2

# Old (Hydra 1.1) @hydra.main(config_path="conf", config_name="config") def main(cfg): ... def main(): cfg = hydra.initialize_and_run(config_path="conf", config_name="config", task_function=my_task) Version 1

This moves Hydra away from rigid inheritance trees (which often broke) toward a more flexible composition model. You can now write: Deprecation of hydra

If you have ever tried to manage a massive Python configuration file full of nested dictionaries, you know the pain. That is why the open-source community fell in love with (from Facebook Research). It allows you to compose dynamic configurations from multiple files and override anything from the command line.

This change allows for better type checking and allows you to run Hydra inside Jupyter Notebooks (finally!) without weird hacks. Yes, but carefully. If you are starting a new project today, use Hydra 1.2 . The new composition rules and Jupyter support are worth it.

If you are on a legacy pipeline of 10,000+ lines of configs, pin your version to hydra-core==1.1.2 for now, but plan the migration. The deprecation of hydra.main means you will need to refactor your entry point logic.