Principle:Langchain ai Langchain Version Bumping
Overview
Version Bumping is the practice of updating a package's version identifier according to semantic versioning rules prior to building and publishing a release.
Description
In a monorepo containing multiple independently-versioned packages, each package maintains its own version string. Before a release, a maintainer manually edits this version string to reflect the nature of the upcoming changes:
- Major version increments signal breaking API changes.
- Minor version increments add new functionality in a backward-compatible manner.
- Patch version increments address backward-compatible bug fixes.
- Pre-release suffixes (e.g.,
rc1,dev0) indicate release candidates or development builds that are not yet considered stable.
The version string serves as the single source of truth consumed by the build system (to stamp artifacts) and by the CI pipeline (to tag releases and compute changelogs). Keeping the version in the project metadata file rather than in a separate version file avoids drift between the declared version and the actually-built artifact.
Usage
Use version bumping whenever:
- A new stable release is being cut for any package in the monorepo.
- A release candidate or pre-release build is needed for testing (e.g.,
0.3.0rc1). - A hotfix patch must be published to address a production issue (patch-level increment).
Practical Guide
The general pattern for bumping a version follows these steps:
1. Determine the current version from the package metadata file.
2. Decide the increment level (major / minor / patch / pre-release).
3. Edit the version field in the metadata file.
4. Commit the change to the repository.
5. Trigger the release pipeline (which reads the new version).
Pseudocode:
current_version = read_version_from_metadata("pyproject.toml")
new_version = compute_next_version(current_version, increment="minor")
write_version_to_metadata("pyproject.toml", new_version)
commit_and_push("Bump version to " + new_version)
Pre-release convention:
Pre-release versions use a suffix appended directly to the base version string:
0.3.0rc1 -- first release candidate for 0.3.0
0.3.0rc2 -- second release candidate
0.3.0dev0 -- development snapshot
0.3.0 -- final stable release