mirror of
https://github.com/lancedb/lancedb.git
synced 2025-12-25 14:29:56 +00:00
5349e8b1db
This PR changes the release process. Some parts are more complex, and other parts I've simplified. ## Simplifications * Combined `Create Release Commit` and `Create Python Release Commit` into a single workflow. By default, it does a release of all packages, but you can still choose to make just a Python or just Node/Rust release through the arguments. This will make it rarer that we create a Node release but forget about Python or vice-versa. * Releases are automatically generated once a tag is pushed. This eliminates the manual step of creating the release. * Release notes are automatically generated and changes are categorized based on the PR labels. * Removed the use of `LANCEDB_RELEASE_TOKEN` in favor of just using `GITHUB_TOKEN` where it wasn't necessary. In the one place it is necessary, I left a comment as to why it is. * Reused the version in `python/Cargo.toml` so we don't have two different versions in Python LanceDB. ## New changes * We now can create `preview` / `beta` releases. By default `Create Release Commit` will create a preview release, but you can select a "stable" release type and it will create a full stable release. * For Python, pre-releases go to fury.io instead of PyPI * `bump2version` was deprecated, so upgraded to `bump-my-version`. This also seems to better support semantic versioning with pre-releases. * `ci` changes will now be shown in the changelog, allowing changes like this to be visible to users. `chore` is still hidden. ## Versioning **NOTE**: unlike how it is in lance repo right now, the version in main is the last one released, including beta versions. --------- Co-authored-by: Lance Release <lance-dev@lancedb.com> Co-authored-by: Weston Pace <weston.pace@gmail.com>
88 lines
4.6 KiB
Markdown
88 lines
4.6 KiB
Markdown
# Release process
|
|
|
|
There are five total packages we release. Three are the `lancedb` packages
|
|
for Python, Rust, and Node.js. The other two are the legacy `vectordb`
|
|
packages for Rust and node.js.
|
|
|
|
The Python package is versioned and released separately from the Rust and Node.js
|
|
ones. For Rust and Node.js, the release process is shared between `lancedb` and
|
|
`vectordb` for now.
|
|
|
|
## Preview releases
|
|
|
|
LanceDB has full releases about every 2 weeks, but in between we make frequent
|
|
preview releases. These are released as `0.x.y.betaN` versions. They receive the
|
|
same level of testing as normal releases and let you get access to the latest
|
|
features. However, we do not guarantee that preview releases will be available
|
|
more than 6 months after they are released. We may delete the preview releases
|
|
from the packaging index after a while. Once your application is stable, we
|
|
recommend switching to full releases, which will never be removed from package
|
|
indexes.
|
|
|
|
## Making releases
|
|
|
|
The release process uses a handful of GitHub actions to automate the process.
|
|
|
|
```text
|
|
┌─────────────────────┐
|
|
│Create Release Commit│
|
|
└─┬───────────────────┘
|
|
│ ┌────────────┐ ┌──►Python GH Release
|
|
├──►(tag) python-vX.Y.Z ───►│PyPI Publish├─┤
|
|
│ └────────────┘ └──►Python Wheels
|
|
│
|
|
│ ┌───────────┐
|
|
└──►(tag) vX.Y.Z ───┬──────►│NPM Publish├──┬──►Rust/Node GH Release
|
|
│ └───────────┘ │
|
|
│ └──►NPM Packages
|
|
│ ┌─────────────┐
|
|
└──────►│Cargo Publish├───►Cargo Release
|
|
└─────────────┘
|
|
```
|
|
|
|
To start a release, trigger a `Create Release Commit` action from
|
|
[the workflows page](https://github.com/lancedb/lancedb/actions/workflows/make-release-commit.yml)
|
|
(Click on "Run workflow").
|
|
|
|
* **For a preview release**, leave the default parameters.
|
|
* **For a stable release**, set the `release_type` input to `stable`.
|
|
|
|
> [!IMPORTANT]
|
|
> If there was a breaking change since the last stable release, and we haven't
|
|
> done so yet, we should increment the minor version. The CI will detect if this
|
|
> is needed and fail the `Create Release Commit` job. To fix, select the
|
|
> "bump minor version" option.
|
|
|
|
## Breaking changes
|
|
|
|
We try to avoid breaking changes, but sometimes they are necessary. When there
|
|
are breaking changes, we will increment the minor version. (This is valid
|
|
semantic versioning because we are still in `0.x` versions.)
|
|
|
|
When a PR makes a breaking change, the PR author should mark the PR using the
|
|
conventional commit markers: either exclamation mark after the type
|
|
(such as `feat!: change signature of func`) or have `BREAKING CHANGE` in the
|
|
body of the PR. A CI job will add a `breaking-change` label to the PR, which is
|
|
what will ultimately be used to CI to determine if the minor version should be
|
|
incremented.
|
|
|
|
> [!IMPORTANT]
|
|
> Reviewers should check that PRs with breaking changes receive the `breaking-change`
|
|
> label. If a PR is missing the label, please add it, even if after it was merged.
|
|
> This label is used in the release process.
|
|
|
|
Some things that are considered breaking changes:
|
|
|
|
* Upgrading `lance` to a new minor version. Minor version bumps in Lance are
|
|
considered breaking changes during `0.x` releases. This can change behavior
|
|
in LanceDB.
|
|
* Upgrading a dependency pin that is in the Rust API. In particular, upgrading
|
|
`DataFusion` and `Arrow` are breaking changes. Changing dependencies that are
|
|
not exposed in our public API are not considered breaking changes.
|
|
* Changing the signature of a public function or method.
|
|
* Removing a public function or method.
|
|
|
|
We do make exceptions for APIs that are marked as experimental. These are APIs
|
|
that are under active development and not in major use. These changes should not
|
|
receive the `breaking-change` label.
|