rust/lancedb
1
0
Fork 0
mirror of https://github.com/lancedb/lancedb.git synced 2025-12-25 14:29:56 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
python-v0.9.0-beta.4
lancedb/release_process.md
Will Jones 5349e8b1db ci: make preview releases (#1302) 
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>
2024-05-17 11:24:38 -07:00

4.6 KiB
Raw Permalink Blame History

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.

  ┌─────────────────────┐                                                
  │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 (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.