From ecf99f011249dcbc7471c66364443a06b98aa76b Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Thu, 30 Jun 2022 15:27:19 -0700 Subject: [PATCH 01/14] Update docs Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 66 +++++++-------------------------- 1 file changed, 14 insertions(+), 52 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index af573c92c76..e1eeaddc9cc 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -4,60 +4,22 @@ For Feast maintainers, these are the concrete steps for making a new release. -1. For new major or minor release, create and check out the release branch for the new stream, e.g. `v0.6-branch`. For a patch version, check out the stream's release branch. -2. Update the [CHANGELOG.md](../../CHANGELOG.md). See the [Creating a change log](release-process.md#creating-a-change-log) guide and commit - * Make to review each PR in the changelog to [flag any breaking changes and deprecation.](release-process.md#flag-breaking-changes-and-deprecations) -3. Update versions for the release/release candidate with a commit: - 1. In the root `pom.xml`, remove `-SNAPSHOT` from the `` property, update versions, and commit. - 2. Tag the commit with the release version, using a `v` and `sdk/go/v` prefixes - * for a release candidate, create tags `vX.Y.Z-rc.N`and `sdk/go/vX.Y.Z-rc.N` - * for a stable release `X.Y.Z` create tags `vX.Y.Z` and `sdk/go/vX.Y.Z` - 3. Check that versions are updated with `make lint-versions`. - 4. If changes required are flagged by the version lint, make the changes, amend the commit and move the tag to the new commit. -4. Push the commits and tags. Make sure the CI passes. - * If the CI does not pass, or if there are new patches for the release fix, repeat step 2 & 3 with release candidates until stable release is achieved. -5. Bump to the next patch version in the release branch, append `-SNAPSHOT` in `pom.xml` and push. -6. Create a PR against master to: - 1. Bump to the next major/minor version and append `-SNAPSHOT` . - 2. Add the change log by applying the change log commit created in step 2. - 3. Check that versions are updated with `env TARGET_MERGE_BRANCH=master make lint-versions` -7. Create a [GitHub release](https://github.com/feast-dev/feast/releases) which includes a summary of im~~p~~ortant changes as well as any artifacts associated with the release. Make sure to include the same change log as added in [CHANGELOG.md](../../CHANGELOG.md). Use `Feast vX.Y.Z` as the title. - -When a tag that matches a Semantic Version string is pushed, CI will automatically build and push the relevant artifacts to their repositories or package managers (docker images, Python wheels, etc). JVM artifacts are promoted from Sonatype OSSRH to Maven Central, but it sometimes takes some time for them to be available. The `sdk/go/v tag` is required to version the Go SDK go module so that users can go get a specific tagged release of the Go SDK. - -### Creating a change log - -We use an [open source change log generator](https://hub.docker.com/r/ferrarimarco/github-changelog-generator/) to generate change logs. The process still requires a little bit of manual effort. - -1. Create a GitHub token as [per these instructions](https://github.com/github-changelog-generator/github-changelog-generator#github-token). The token is used as an input argument (`-t`) to the change log generator. -2. The change log generator configuration below will look for unreleased changes on a specific branch. The branch will be `master` for a major/minor release, or a release branch (`v0.4-branch`) for a patch release. You will need to set the branch using the `--release-branch` argument. -3. You should also set the `--future-release` argument. This is the version you are releasing. The version can still be changed at a later date. -4. Update the arguments below and run the command to generate the change log to the console. - -``` -docker run -it --rm ferrarimarco/github-changelog-generator \ ---user feast-dev \ ---project feast \ ---release-branch \ ---future-release \ ---unreleased-only \ ---no-issues \ ---bug-labels kind/bug \ ---enhancement-labels kind/feature \ ---breaking-labels compat/breaking \ --t \ ---max-issues 1 \ --o -``` - -1. Review each change log item. - * Make sure that sentences are grammatically correct and well formatted (although we will try to enforce this at the PR review stage). - * Make sure that each item is categorised correctly. You will see the following categories: `Breaking changes`, `Implemented enhancements`, `Fixed bugs`, and `Merged pull requests`. Any unlabelled PRs will be found in `Merged pull requests`. It's important to make sure that any `breaking changes`, `enhancements`, or `bug fixes` are pulled up out of `merged pull requests` into the correct category. Housekeeping, tech debt clearing, infra changes, or refactoring do not count as `enhancements`. Only enhancements a user benefits from should be listed in that category. - * Make sure that the "Full Change log" link is actually comparing the correct tags (normally your released version against the previously version). - * Make sure that release notes and breaking changes are present. +1. Merge upstream master changes into your fork. +2. Create a tag manually for the release on your fork. For example, if your release is on version 0.22.0, create a tag by doing the following. + - Checkout master branch and run `git tag v0.22.0`. + - Run `git push --tags` to push the tag to remote. +3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. +4. Look for the header `This workflow has a workflow_dispatch event trigger.` and click `Run Workflow` on the right. +5. Run the branch off of the tag you just created(`v0.22.0`) in this case and verify that the workflow worked. +6. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your already generated personal access token. + - The personal access token should have all of the permissions under the `repo` checkbox. +7. Access the `Actions` tab on the main `feast-dev/feast` repo and find the `release` action. +8. Look for the header `This workflow has a workflow_dispatch event trigger.` again and click `Run Workflow` on the right. +9. Try the dry run first with your personal access token. If this succeeds, uncheck `Dry Run` and run the release. +10. All of the jobs should succeed besides the UI job which needs to be released separately. Ping a maintainer on Slack to run the UI release manually. ### Flag Breaking Changes & Deprecations It's important to flag breaking changes and deprecation to the API for each release so that we can maintain API compatibility. -Developers should have flagged PRs with breaking changes with the `compat/breaking` label. However, it's important to double check each PR's release notes and contents for changes that will break API compatibility and manually label `compat/breaking` to PRs with undeclared breaking changes. The change log will have to be regenerated if any new labels have to be added. +Developers should have flagged PRs with breaking changes with the `compat/breaking` label. However, it's important to double check each PR's release notes and contents for changes that will break API compatibility and manually label `compat/breaking` to PRs with undeclared breaking changes. \ No newline at end of file From 54d9fbe8df13590f7684a3744aaa41fccd9a8c86 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Thu, 30 Jun 2022 16:13:51 -0700 Subject: [PATCH 02/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index e1eeaddc9cc..74ce368270c 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -4,6 +4,8 @@ For Feast maintainers, these are the concrete steps for making a new release. +### Pre-release Verification + 1. Merge upstream master changes into your fork. 2. Create a tag manually for the release on your fork. For example, if your release is on version 0.22.0, create a tag by doing the following. - Checkout master branch and run `git tag v0.22.0`. @@ -11,11 +13,13 @@ For Feast maintainers, these are the concrete steps for making a new release. 3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. 4. Look for the header `This workflow has a workflow_dispatch event trigger.` and click `Run Workflow` on the right. 5. Run the branch off of the tag you just created(`v0.22.0`) in this case and verify that the workflow worked. -6. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your already generated personal access token. + +### Release +6. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. - The personal access token should have all of the permissions under the `repo` checkbox. 7. Access the `Actions` tab on the main `feast-dev/feast` repo and find the `release` action. 8. Look for the header `This workflow has a workflow_dispatch event trigger.` again and click `Run Workflow` on the right. -9. Try the dry run first with your personal access token. If this succeeds, uncheck `Dry Run` and run the release. +9. Try the dry run first with your personal access token. If this succeeds, uncheck `Dry Run` and run the release workflow. 10. All of the jobs should succeed besides the UI job which needs to be released separately. Ping a maintainer on Slack to run the UI release manually. ### Flag Breaking Changes & Deprecations From 00651be3960a10c61912dc05cd7d0f9875a98bc4 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Thu, 30 Jun 2022 16:49:06 -0700 Subject: [PATCH 03/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index 74ce368270c..38a780b6ef6 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -8,15 +8,15 @@ For Feast maintainers, these are the concrete steps for making a new release. 1. Merge upstream master changes into your fork. 2. Create a tag manually for the release on your fork. For example, if your release is on version 0.22.0, create a tag by doing the following. - - Checkout master branch and run `git tag v0.22.0`. - - Run `git push --tags` to push the tag to remote. + - Checkout master branch and run `git tag v0.22.0`. + - Run `git push --tags` to push the tag to remote. 3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. 4. Look for the header `This workflow has a workflow_dispatch event trigger.` and click `Run Workflow` on the right. -5. Run the branch off of the tag you just created(`v0.22.0`) in this case and verify that the workflow worked. +5. Run the branch off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked. ### Release 6. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. - - The personal access token should have all of the permissions under the `repo` checkbox. + - The personal access token should have all of the permissions under the `repo` checkbox. 7. Access the `Actions` tab on the main `feast-dev/feast` repo and find the `release` action. 8. Look for the header `This workflow has a workflow_dispatch event trigger.` again and click `Run Workflow` on the right. 9. Try the dry run first with your personal access token. If this succeeds, uncheck `Dry Run` and run the release workflow. From 748213b2d5b8715cf2e9e8706b1da8bc54b2b251 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Thu, 30 Jun 2022 16:51:03 -0700 Subject: [PATCH 04/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index 38a780b6ef6..a87a9511271 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -11,16 +11,17 @@ For Feast maintainers, these are the concrete steps for making a new release. - Checkout master branch and run `git tag v0.22.0`. - Run `git push --tags` to push the tag to remote. 3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. -4. Look for the header `This workflow has a workflow_dispatch event trigger.` and click `Run Workflow` on the right. +4. Look for the header `This workflow has a workflow_dispatch event trigger` and click `Run Workflow` on the right. 5. Run the branch off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked. ### Release -6. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. +1. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. - The personal access token should have all of the permissions under the `repo` checkbox. -7. Access the `Actions` tab on the main `feast-dev/feast` repo and find the `release` action. -8. Look for the header `This workflow has a workflow_dispatch event trigger.` again and click `Run Workflow` on the right. -9. Try the dry run first with your personal access token. If this succeeds, uncheck `Dry Run` and run the release workflow. -10. All of the jobs should succeed besides the UI job which needs to be released separately. Ping a maintainer on Slack to run the UI release manually. +2. Access the `Actions` tab on the main `feast-dev/feast` repo and find the `release` action. +3. Look for the header `This workflow has a workflow_dispatch event trigger` again and click `Run Workflow` on the right. +4. Try the dry run first with your personal access token. If this succeeds, uncheck `Dry Run` and run the release workflow. +5. All of the jobs should succeed besides the UI job which needs to be released separately. Ping a maintainer on Slack to run the UI release manually. +6. Try to install the feast release in your local environment and test out the `feast init` -> `feast apply` workflow to verify as a sanity check that the release worked correctly. ### Flag Breaking Changes & Deprecations From 136258db4f5c9efbdb662aa801b1d968b8a4d8a3 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 10:15:35 -0700 Subject: [PATCH 05/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index a87a9511271..b54b14889e5 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -4,7 +4,7 @@ For Feast maintainers, these are the concrete steps for making a new release. -### Pre-release Verification +### Pre-release Verification (Verification that wheels are built correctly) 1. Merge upstream master changes into your fork. 2. Create a tag manually for the release on your fork. For example, if your release is on version 0.22.0, create a tag by doing the following. From b779e51386d4a00ad60b519b26f9f2bb89efd903 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 10:16:07 -0700 Subject: [PATCH 06/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index b54b14889e5..30042482765 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -7,7 +7,7 @@ For Feast maintainers, these are the concrete steps for making a new release. ### Pre-release Verification (Verification that wheels are built correctly) 1. Merge upstream master changes into your fork. -2. Create a tag manually for the release on your fork. For example, if your release is on version 0.22.0, create a tag by doing the following. +2. Create a tag manually for the release on your fork. For example, if your release doing a release for version 0.22.0, create a tag by doing the following. - Checkout master branch and run `git tag v0.22.0`. - Run `git push --tags` to push the tag to remote. 3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. From 1820ae968a25338a40fc83d9ff6c7f05579c1600 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 10:24:45 -0700 Subject: [PATCH 07/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index 30042482765..d766e83e8b0 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -22,9 +22,3 @@ For Feast maintainers, these are the concrete steps for making a new release. 4. Try the dry run first with your personal access token. If this succeeds, uncheck `Dry Run` and run the release workflow. 5. All of the jobs should succeed besides the UI job which needs to be released separately. Ping a maintainer on Slack to run the UI release manually. 6. Try to install the feast release in your local environment and test out the `feast init` -> `feast apply` workflow to verify as a sanity check that the release worked correctly. - -### Flag Breaking Changes & Deprecations - -It's important to flag breaking changes and deprecation to the API for each release so that we can maintain API compatibility. - -Developers should have flagged PRs with breaking changes with the `compat/breaking` label. However, it's important to double check each PR's release notes and contents for changes that will break API compatibility and manually label `compat/breaking` to PRs with undeclared breaking changes. \ No newline at end of file From cdb5005345efbb27c4206981ed2cc24c576e2a24 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 10:36:52 -0700 Subject: [PATCH 08/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index d766e83e8b0..9745d28a82c 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -12,7 +12,7 @@ For Feast maintainers, these are the concrete steps for making a new release. - Run `git push --tags` to push the tag to remote. 3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. 4. Look for the header `This workflow has a workflow_dispatch event trigger` and click `Run Workflow` on the right. -5. Run the branch off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked. +5. Run the workflow off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked. ### Release 1. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. From 4f1c410ecafd968d4baf0c4d23daba0ea70431ac Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 11:45:47 -0700 Subject: [PATCH 09/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index 9745d28a82c..341c9f50d9e 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -7,7 +7,7 @@ For Feast maintainers, these are the concrete steps for making a new release. ### Pre-release Verification (Verification that wheels are built correctly) 1. Merge upstream master changes into your fork. -2. Create a tag manually for the release on your fork. For example, if your release doing a release for version 0.22.0, create a tag by doing the following. +2. Create a tag manually for the release on your fork. For example, if you are doing a release for version 0.22.0, create a tag by doing the following. - Checkout master branch and run `git tag v0.22.0`. - Run `git push --tags` to push the tag to remote. 3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. From ae4bc72eaa2c5d89d6cb7c40b40f17009578687f Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 11:56:25 -0700 Subject: [PATCH 10/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index 341c9f50d9e..c2a4a6b32a1 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -6,7 +6,7 @@ For Feast maintainers, these are the concrete steps for making a new release. ### Pre-release Verification (Verification that wheels are built correctly) -1. Merge upstream master changes into your fork. +1. Merge upstream master changes into your **fork**. Make sure you are running the workflow off of your fork! 2. Create a tag manually for the release on your fork. For example, if you are doing a release for version 0.22.0, create a tag by doing the following. - Checkout master branch and run `git tag v0.22.0`. - Run `git push --tags` to push the tag to remote. From 256bc63635c2b4a97ca50d29e4fe3111f787b715 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 12:16:59 -0700 Subject: [PATCH 11/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index c2a4a6b32a1..740f66a6fdf 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -4,8 +4,7 @@ For Feast maintainers, these are the concrete steps for making a new release. -### Pre-release Verification (Verification that wheels are built correctly) - +### Pre-release Verification (Verification that wheels are built correctly) for minor release. 1. Merge upstream master changes into your **fork**. Make sure you are running the workflow off of your fork! 2. Create a tag manually for the release on your fork. For example, if you are doing a release for version 0.22.0, create a tag by doing the following. - Checkout master branch and run `git tag v0.22.0`. @@ -14,6 +13,13 @@ For Feast maintainers, these are the concrete steps for making a new release. 4. Look for the header `This workflow has a workflow_dispatch event trigger` and click `Run Workflow` on the right. 5. Run the workflow off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked. +### Pre-release Verification (Verification that wheels are built correctly) for patch release. +1. Check out the branch of your release (e.g `v0.22-branch` on your local fork) and push this to your fork. +2. Cherry pick commits that are relevant to the patch release onto your forked branch. +3. Add a patch release tag (e.g `v0.22.1`) by running `git tag `. +4. Push tags to origin branch with `git push origin `. +5. Kick off `build_wheels` workflow in the same way as is detailed in the last section off of the patch release tag. + ### Release 1. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. - The personal access token should have all of the permissions under the `repo` checkbox. From a8ca1252057993fbdaf8fe3ba89d1eaeefae4049 Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 12:22:42 -0700 Subject: [PATCH 12/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index 740f66a6fdf..7656025f9c2 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -14,11 +14,11 @@ For Feast maintainers, these are the concrete steps for making a new release. 5. Run the workflow off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked. ### Pre-release Verification (Verification that wheels are built correctly) for patch release. -1. Check out the branch of your release (e.g `v0.22-branch` on your local fork) and push this to your fork. +1. Check out the branch of your release (e.g `v0.22-branch` on your local **fork**) and push this to your fork (`git push -u origin `). 2. Cherry pick commits that are relevant to the patch release onto your forked branch. -3. Add a patch release tag (e.g `v0.22.1`) by running `git tag `. -4. Push tags to origin branch with `git push origin `. -5. Kick off `build_wheels` workflow in the same way as is detailed in the last section off of the patch release tag. +3. Checkout the release branch and add a patch release tag (e.g `v0.22.1`) by running `git tag `. +4. Push tags to your origin branch with `git push origin `. +5. Kick off `build_wheels` workflow in the same way as is detailed in the last section on of the patch release tag. ### Release 1. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. From 8bc5b1c8675fc7910eafceccaf7165a7ca30bb4f Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Fri, 1 Jul 2022 12:55:31 -0700 Subject: [PATCH 13/14] Fix Signed-off-by: Kevin Zhang --- Makefile | 2 +- go.mod | 6 ++---- go.sum | 7 ++++--- setup.py | 2 +- 4 files changed, 8 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 176e2cb3545..433510ae6ea 100644 --- a/Makefile +++ b/Makefile @@ -172,7 +172,7 @@ install-go-proto-dependencies: install-go-ci-dependencies: # TODO: currently gopy installation doesn't work w/o explicit go get in the next line # TODO: there should be a better way to install gopy - go get github.com/go-python/gopy@v0.4.0 + go get github.com/go-python/gopy@v0.4.4 go install golang.org/x/tools/cmd/goimports # The `go get` command on the previous lines download the lib along with replacing the dep to `feast-dev/gopy` # but the following command is needed to install it for some reason. diff --git a/go.mod b/go.mod index 90ddb93e21c..444d37ac7ee 100644 --- a/go.mod +++ b/go.mod @@ -2,12 +2,10 @@ module github.com/feast-dev/feast go 1.17 -replace github.com/go-python/gopy v0.4.0 => github.com/feast-dev/gopy v0.4.1-0.20220429180328-4257ac71a4d0 - require ( github.com/apache/arrow/go/v8 v8.0.0 github.com/ghodss/yaml v1.0.0 - github.com/go-python/gopy v0.4.0 + github.com/go-python/gopy v0.4.4 github.com/go-redis/redis/v8 v8.11.4 github.com/golang/protobuf v1.5.2 github.com/google/uuid v1.3.0 @@ -38,7 +36,7 @@ require ( github.com/pmezard/go-difflib v1.0.0 // indirect github.com/zeebo/xxh3 v1.0.2 // indirect golang.org/x/exp v0.0.0-20220407100705-7b9b53b0aca4 // indirect - golang.org/x/mod v0.6.0-dev.0.20220106191415-9b9b3d81d5e3 // indirect + golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4 // indirect golang.org/x/net v0.0.0-20220407224826-aac1ed45d8e3 // indirect golang.org/x/sys v0.0.0-20220412211240-33da011f77ad // indirect golang.org/x/text v0.3.7 // indirect diff --git a/go.sum b/go.sum index 933ecf6b29c..d28b3acf5a3 100644 --- a/go.sum +++ b/go.sum @@ -87,8 +87,6 @@ github.com/envoyproxy/go-control-plane v0.9.10-0.20210907150352-cf90f659a021/go. github.com/envoyproxy/go-control-plane v0.10.2-0.20220325020618-49ff273808a1/go.mod h1:KJwIaB5Mv44NWtYuAOFCVOjcI94vtpEz2JU/D2v6IjE= github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7+kN2VEUnK/pcBlmesArF7c= github.com/fatih/color v1.7.0/go.mod h1:Zm6kSWBoL9eyXnKyktHP6abPY2pDugNf5KwzbycvMj4= -github.com/feast-dev/gopy v0.4.1-0.20220429180328-4257ac71a4d0 h1:Go714ObVP1O+a6qK7haXVL28QNm6WMD8bwnN9EA8PlM= -github.com/feast-dev/gopy v0.4.1-0.20220429180328-4257ac71a4d0/go.mod h1:ZO6vpitQ61NVoQP/2yOubPS6ET5pP3CAWCiMYn5eqCc= github.com/fogleman/gg v1.2.1-0.20190220221249-0403632d5b90/go.mod h1:R/bRT+9gY/C5z7JzPU0zXsXHKM4/ayA+zqcVNZzPa1k= github.com/fogleman/gg v1.3.0/go.mod h1:R/bRT+9gY/C5z7JzPU0zXsXHKM4/ayA+zqcVNZzPa1k= github.com/franela/goblin v0.0.0-20200105215937-c9ffbefa60db/go.mod h1:7dvUGVsVBjqR7JHJk0brhHOZYGmfBYOrK0ZhYMEtBr4= @@ -112,6 +110,8 @@ github.com/go-logfmt/logfmt v0.3.0/go.mod h1:Qt1PoO58o5twSAckw1HlFXLmHsOX5/0LbT9 github.com/go-logfmt/logfmt v0.4.0/go.mod h1:3RMwSq7FuexP4Kalkev3ejPJsZTpXXBr9+V4qmtdjCk= github.com/go-logfmt/logfmt v0.5.0/go.mod h1:wCYkCAKZfumFQihp8CzCvQ3paCTfi41vtzG1KdI/P7A= github.com/go-logr/logr v0.4.0/go.mod h1:z6/tIYblkpsD+a4lm/fGIIU9mZ+XfAiaFtq7xTgseGU= +github.com/go-python/gopy v0.4.4 h1:3LTsrfVcmg2VEM6wU+eh4d9EZn5H2iogObXjiQHrF8Q= +github.com/go-python/gopy v0.4.4/go.mod h1:tlA/KcD7rM8B+NQJR4SASwiinfKY0aiMFanHszR8BZA= github.com/go-redis/redis/v8 v8.11.4 h1:kHoYkfZP6+pe04aFTnhDH6GDROa5yJdHJVNxV3F46Tg= github.com/go-redis/redis/v8 v8.11.4/go.mod h1:2Z2wHZXdQpCDXEGzqMockDpNyYvi2l4Pxt6RJr792+w= github.com/go-sql-driver/mysql v1.4.0/go.mod h1:zAC/RDZ24gD3HViQzih4MyKcchzm+sOG5ZlKdlhCg5w= @@ -439,8 +439,9 @@ golang.org/x/mod v0.5.1/go.mod h1:5OXOZSfqPIIbmVBIIKWRFfZjPR0E5r58TLhUjH0a2Ro= golang.org/x/mod v0.5.1/go.mod h1:5OXOZSfqPIIbmVBIIKWRFfZjPR0E5r58TLhUjH0a2Ro= golang.org/x/mod v0.6.0-dev.0.20211013180041-c96bc1413d57/go.mod h1:3p9vT2HGsQu2K1YbXdKPJLVgG5VJdoTa1poYQBtP1AY= golang.org/x/mod v0.6.0-dev.0.20211013180041-c96bc1413d57/go.mod h1:3p9vT2HGsQu2K1YbXdKPJLVgG5VJdoTa1poYQBtP1AY= -golang.org/x/mod v0.6.0-dev.0.20220106191415-9b9b3d81d5e3 h1:kQgndtyPBW/JIYERgdxfwMYh3AVStj88WQTlNDi2a+o= golang.org/x/mod v0.6.0-dev.0.20220106191415-9b9b3d81d5e3/go.mod h1:3p9vT2HGsQu2K1YbXdKPJLVgG5VJdoTa1poYQBtP1AY= +golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4 h1:6zppjxzCulZykYSLyVDYbneBfbaBIQPYMevg0bEwv2s= +golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4= golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= golang.org/x/net v0.0.0-20180826012351-8a410e7b638d/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= golang.org/x/net v0.0.0-20180906233101-161cd47e91fd/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= diff --git a/setup.py b/setup.py index 217b2e10118..ace34e6c078 100644 --- a/setup.py +++ b/setup.py @@ -430,7 +430,7 @@ def build_extension(self, ext: Extension): destination = os.path.dirname(os.path.abspath(self.get_ext_fullpath(ext.name))) subprocess.check_call(["go", "install", "golang.org/x/tools/cmd/goimports"], env={"PATH": bin_path, **go_env}) - subprocess.check_call(["go", "get", "github.com/go-python/gopy@v0.4.0"], + subprocess.check_call(["go", "get", "github.com/go-python/gopy@v0.4.4"], env={"PATH": bin_path, **go_env}) subprocess.check_call(["go", "install", "github.com/go-python/gopy"], env={"PATH": bin_path, **go_env}) From bb2e4c7944185205bbec0f1972426facbda78c0c Mon Sep 17 00:00:00 2001 From: Kevin Zhang Date: Tue, 5 Jul 2022 14:35:05 -0700 Subject: [PATCH 14/14] Fix Signed-off-by: Kevin Zhang --- docs/project/release-process.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/project/release-process.md b/docs/project/release-process.md index 7656025f9c2..f7102d13c39 100644 --- a/docs/project/release-process.md +++ b/docs/project/release-process.md @@ -8,10 +8,10 @@ For Feast maintainers, these are the concrete steps for making a new release. 1. Merge upstream master changes into your **fork**. Make sure you are running the workflow off of your fork! 2. Create a tag manually for the release on your fork. For example, if you are doing a release for version 0.22.0, create a tag by doing the following. - Checkout master branch and run `git tag v0.22.0`. - - Run `git push --tags` to push the tag to remote. -3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. + - Run `git push --tags` to push the tag to your forks master branch. +3. Access the `Actions` tab on your github UI on your fork and click the `build_wheels` action. This workflow will build the python sdk wheels for Python 3.8-3.10 on MacOS 10.15 and Linux and verify that these wheels are correct. The publish workflow uses this action to publish the python wheels for a new release to pypi. 4. Look for the header `This workflow has a workflow_dispatch event trigger` and click `Run Workflow` on the right. -5. Run the workflow off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked. +5. Run the workflow off of the tag you just created(`v0.22.0` in this case) and verify that the workflow worked (i.e ensure that all jobs are green). ### Pre-release Verification (Verification that wheels are built correctly) for patch release. 1. Check out the branch of your release (e.g `v0.22-branch` on your local **fork**) and push this to your fork (`git push -u origin `). @@ -20,7 +20,7 @@ For Feast maintainers, these are the concrete steps for making a new release. 4. Push tags to your origin branch with `git push origin `. 5. Kick off `build_wheels` workflow in the same way as is detailed in the last section on of the patch release tag. -### Release +### Release for Python and Java SDK 1. Generate a [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) or retrieve your saved personal access token. - The personal access token should have all of the permissions under the `repo` checkbox. 2. Access the `Actions` tab on the main `feast-dev/feast` repo and find the `release` action.