chore!: release v1.0.0 packages #552
Conversation
|
There will be another PR to update the dependencies in sdk package. |
|
There's nothing in this PR. I would have expected something like a Github Actions workflow for doing a release. |
chore! will force it to release a major version. Will we not do pre-release after this anymore? |
|
What are you proposing the release process would look like? |
packages/sdk/package.json
Outdated
| @@ -27,7 +27,7 @@ | |||
| "license": "MIT", | |||
| "dependencies": { | |||
| "@evoke-platform/context": "latest", | |||
| "@evoke-platform/payment": "^1.0.0-dev.0", | |||
| "@evoke-platform/payment": "latest", | |||
There was a problem hiding this comment.
Should probably change all of these into actual versions, ^1.0.0
There was a problem hiding this comment.
We need to release these packages first before we can update @evoke-platform/sdk dependencies.
There was a problem hiding this comment.
This looks like a workflow for publishing a release. It's not really a CI build and shouldn't call it as such.
| @@ -39,12 +37,12 @@ jobs: | |||
| git config user.name "GitHub Actions Bot" | |||
| git config user.email "<>" | |||
| mv npmrc-ci .npmrc | |||
| npx turbo run release --concurrency 1 --filter=...[baseline] -- --prerelease dev --skip.tag --skip.changelog | |||
| npx turbo run deploy --filter=...[baseline] -- --tag dev | |||
| npx turbo run release --concurrency 1 --filter=...[baseline] -- --skip.tag --skip.changelog | |||
There was a problem hiding this comment.
Don't want to skip tagging or changelog
| on: | ||
| push: | ||
| branches: | ||
| - release/live |
There was a problem hiding this comment.
So we're calling this a "release" branch? Not saying it doesn't work, though want to make sure this won't be confusing to anyone. I do think we don't need /live, not sure what that means.
There was a problem hiding this comment.
Regarding the build process (https://github.com/Evoke-Platform/evoke-sdk/pull/552/files#diff-c471496bcb3ed47397b73d2e3e3aa41a8a679c86accaed9e05676fd9d5987434R28), this is for determining what changed when a PR is merged. It's not going to work for a release build. It probably doesn't work when merging from main to release branches either.
There was a problem hiding this comment.
How is it different if we merge something into main branch versus main/another branch merges into release branch? We still need to determine what changed so we can release new version of those changed packages, right? If we do not filter by baseline then we will update all the packages.
There was a problem hiding this comment.
When you do a release, you'll need to build anything that's changed since the last release, not just what's changed in the last commit.
| git config user.name "GitHub Actions Bot" | ||
| git config user.email "<>" | ||
| mv npmrc-ci .npmrc | ||
| npx turbo run release --concurrency 1 -- --prerelease testing --skip.tag --skip.changelog |
There was a problem hiding this comment.
So this builds and bumps the version on everything regardless of whether anything changed?
There was a problem hiding this comment.
Yes it will bump everything. should it be the same as continuous-integration.yml file?
There was a problem hiding this comment.
Ideally it's only building things that have changed since the last build, i.e. not generating a new version for something that didn't change and is exactly the same as the previous version.
Also, have you experimented locally on what this will do with future commits? I tried simulating new changes and doing releases, but it keeps bumping the version to 2.0.0, similar to the behavior described in absolute-version/commit-and-tag-version#210.
There was a problem hiding this comment.
It does not bump version to 2.0.0 for me after I do fix and feat commits and release. However, the bump version is not quite right for a certain package. for example, I have a fix in context and a feat in payment then it bumps the version to 1.1.0 for both. I think the expected version for context should 1.0.1.
There was a problem hiding this comment.
I didn't have a tag. Once I had the 1.0.0 tag, it seemed to start bump minor/patch version numbers, though yeah, it doesn't understand monorepos so any change anywhere affects all packages.
context v1.0.0
payment v1.0.0
plugin-scripts v1.0.0
plugin v1.0.0
sdk v1.0.0