Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ci: make preview releases #1302

Merged
merged 57 commits into from
May 17, 2024
Merged

ci: make preview releases #1302

merged 57 commits into from
May 17, 2024

Conversation

wjones127
Copy link
Contributor

@wjones127 wjones127 commented May 13, 2024

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.

@github-actions github-actions bot added the ci label May 13, 2024
@github-actions github-actions bot added the Python Python SDK label May 15, 2024
@@ -1,6 +1,6 @@
[package]
name = "lancedb-python"
version = "0.4.10"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This version was completely out of sync.

@wjones127 wjones127 marked this pull request as ready for review May 17, 2024 04:59
Copy link
Contributor

@westonpace westonpace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty epic! Nothing major jumps out at me

ignore_missing_version = false
ignore_missing_files = false
tag = true
sign_tags = false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not right now (plenty on PR already) but should we sign tags at some point?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I just wasn't sure how the signing worked if it's a github user. Something to look into.

Comment on lines 70 to 72
filename = "rust/lancedb/Cargo.toml"
search = "version = \"{current_version}\""
replace = "version = \"{new_version}\""
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If a dependency happens to have the same version as lancedb will this bump that dependency's version as well?

i.e. is this searching for <start_of_line>version = \"{current_version}\" or is it searching for version = ... anywhere in the line?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it requires the start of the line. Reading the docs 1 it's a pretty simple replacement. I'll see if I can switch to a regex that requires a line start.

Footnotes

  1. https://callowayproject.github.io/bump-my-version/howtos/avoid-incorrect-replacements/

Comment on lines 6 to 8
"title": "## 🏆 Highlights",
"labels": ["python", "highlight"],
"exhaustive": true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is cool, I assume this label is applied manually?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah we can add this label manually and it will be added to this section. Was in the template and seemed like a useful idea we can try out.

fetch-depth: 0
lfs: true
token: ${{ secrets.LANCEDB_RELEASE_TOKEN }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this not be GITHUB_TOKEN? (minor nit since this workflow relies on LANCEDB_RELEASE_TOKEN at the moment anyways).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It cannot. When testing if this wasn't set to a user token it the tags we pushed would not trigger a workflow. I'll add a comment to this.

id: python_release_notes
uses: mikepenz/release-changelog-builder-action@v4
with:
configuration: .github/python_release_notes.json
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't we just use .github/release_notes.json here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well the python release notes have special filters that will only show the ones that are labelled python. Though TBH I'm not 100% that's the right way to do it. Maybe I should just exclude anything that says Node but not Python? What do you think about that?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, good point, that process is a little messy right now. If we can get in the habit I think we should start scoping language-specific PR titles with conventional commits. In other words:

feat: some feature that is implemented in all clients
feat(node): node-specific feature
feat(python): python-specific feature
feat(rust): rust-specific feature

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm thinking now we'll just make them share the same template for now, and have people manually edit this for now. Later, we can come up with some way to differentiate them.

=== "Rust"

```shell
cargo add lancedb --version 0.0.1-beta.1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we didn't publish pre-releases for rust? Wouldn't that mean we would need to use a github sha?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah this is a mistake. I will remove that.

Comment on lines 16 to 18
features. However, we do not guarantee that preview releases will be available
more than 6 months after they are released. Once your application is stable, we
recommend switching to stable releases.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, just naively reading this I wonder if people might think we are implying that stable versions will be maintained (e.g. we will make security patches) for six months. I wonder if another blurb on release maintenance (or more accurately, lack thereof) is warranted.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I think part of this is the name "stable" release itself. I should use a different name.

release_process.md Outdated Show resolved Hide resolved
@wjones127 wjones127 merged commit 5349e8b into lancedb:main May 17, 2024
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci Python Python SDK
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants