LangChain 发布

LangChain 生态系统由多个组件包组成（例如，@langchain/core、langchain、@langchain/community、@langchain/langgraph、合作伙伴包等）。

版本控制

langchain 和 @langchain/core

langchain 和 @langchain/core 遵循 语义化版本控制，格式为 0.Y.Z。这些包正处于快速开发阶段，因此目前的主版本号为 0。

次版本号（minor）增加的情况包括：

• 任何被标记为 beta 的公共接口发生破坏性变更。

补丁版本号（patch）增加的情况包括：

• Bug 修复
• 新功能添加
• 私有接口的任何变更
• beta 功能的任何变更

在升级次版本时，用户应查阅破坏性变更和弃用功能的列表。

有时，我们会将某些版本标记为 发布候选版（release candidate）。这些版本计划作为稳定版本发布，但我们希望在正式发布前获取社区的反馈。
发布候选版本的格式为 0.Y.Z-rc.N。例如，0.2.0-rc.1。如果没有发现问题，该发布候选版将作为稳定版本发布，版本号相同。
如果发现问题，我们将发布一个新的发布候选版，并增加 N 的值（例如，0.2.0-rc.2）。

LangChain 生态系统中的其他包

生态系统中的其他包（包括用户包）可以采用不同的版本控制方案，但通常应绑定到 langchain 和 @langchain/core 的特定次版本。

发布节奏

我们预计 langchain 和 @langchain/core 的 次版本（例如，从 0.2.0 到 0.3.0）之间至少间隔 2-3 个月，因为这些版本可能包含破坏性变更。

补丁版本会频繁发布，因为它们包含 bug 修复和新功能。

API 稳定性

大语言模型（LLM）应用的开发是一个快速发展的领域，我们不断从用户和社区中学习。因此，我们预计 langchain 和 @langchain/core 中的 API 将持续演进以更好地满足用户需求。

尽管 langchain 和 @langchain/core 当前仍处于 1.0 之前的版本，但我们致力于在这些包中维护 API 的稳定性。

• 对公共 API 的破坏性变更将导致次版本号递增（第二位数字）
• 任何 bug 修复或新功能将导致补丁版本号递增（第三位数字）

我们通常会尽量避免不必要的变更，并为即将移除的功能提供弃用策略。

其他包的稳定性

LangChain 生态系统中其他包的稳定性可能有所不同：

• @langchain/community 是一个社区维护的包，包含第三方集成。虽然我们会尽力审核和测试 @langchain/community 中的变更，但由于包含大量社区贡献，该包的破坏性变更频率预计将高于 langchain 和 @langchain/core。
• 合作伙伴包可能遵循不同的稳定性和版本控制策略，用户应参考这些包的文档了解更多信息；但通常这些包应是稳定的。

什么是“API 稳定性”？

API 稳定性意味着：

• 所有公共 API（本文档中的一切内容）不会在不提供向后兼容别名的情况下被移动或重命名。
• 如果向这些 API 添加了新功能——这是有可能的——不会破坏或更改现有方法的含义。换句话说，“稳定”并不（一定）意味着“完整”。
• 如果由于某种原因必须移除或替换一个被声明为稳定的 API，它将被标记为弃用，但在至少两个次版本中仍将保留。调用弃用方法时会发出警告。

标记为内部的 API

某些 API 会被明确标记为“内部”，方式如下：

• 一些文档会提及内部内容并说明其为内部内容。如果文档说明某项为内部内容，它可能会发生变化。
• 函数、方法和其他以单个下划线（_）开头的对象。如果某个方法以单个 _ 开头，则它属于内部 API。
  • 例外： 某些方法以 _ 开头，但没有实现。这些方法是供子类提供实现的。这类方法通常是 LangChain 公共 API 的一部分。

弃用策略

在更好的替代方案可用之前，我们通常会避免弃用功能。

当某个功能被弃用时，它将在当前次版本和下一个次版本中继续工作。之后，该功能将被移除。

由于我们预计次版本之间的间隔至少为 2-3 个月，这意味着一个功能可能在被弃用后 2-6 个月内被移除。

在某些情况下，如果某个功能不会对包造成问题，我们可能会允许其在代码库中存在更长时间，以减少对用户的负担。