[Big Chore] Multi versioning and automatic changelog generation #335
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
…in permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…in permissions Co-authored-by: Copilot Autofix powered by AI <62310815+github-advanced-security[bot]@users.noreply.github.com>
…c/jss-8623-changeset-multiver # Conflicts: # lerna.json # packages/create-content-sdk-app/package.json
|
illiakovalenko
left a comment
illiakovalenko
left a comment
There was a problem hiding this comment.
The proposal looks better now 👍
Please find my comments below.
| echo "### Next Steps:" >> $GITHUB_STEP_SUMMARY | ||
| echo "1. Checkout the branch: \`git checkout $BRANCH_NAME\`" >> $GITHUB_STEP_SUMMARY | ||
| echo "2. Cherrypick or add patch changes" >> $GITHUB_STEP_SUMMARY | ||
| echo "3. Add changesets (\`yarn changeset\`)" >> $GITHUB_STEP_SUMMARY |
There was a problem hiding this comment.
We need to add a step to "open PR", since it's not allowed to push directly to release branch, that is expected, changes should be reviewed first
There was a problem hiding this comment.
@art-alexeyenko There is still no step to "create" a pull request, you can't push directly to "release" branch. In step 4 it's still mentioned that I can push changes directly
There was a problem hiding this comment.
@illiakovalenko should we revisit this for simplicity? Patches are usually cherrypicks. Managing release prep pull request with cherrypicks + changeset release pull request is the type of complexity we try to avoid
There was a problem hiding this comment.
@art-alexeyenko the thing that we can't really allow to push directly to release branch, since it should be reviewed in any case and sometimes people are doing mistakes even when doing cherrypicks
Description / Motivation
Introduction of the
searchpackage is throwing a wrench in our cozy versioning management, where one version described all. Future changes will throw more wrenches, so we need to support multi-versioning and independent package publish for our monorepo.The How
New flow includes:
changesets:lerna:changesets publishdoes not work well with dry run publishes into internal npm feed)The main (latest release) flow is the following:
cascade-version. The logic is similar tochangeset version, but all the base package version bumps will cascade over to dependendents. I.e.core@1.4.0 -> core@1.5.0update will result in minor version change forreact,nextjsand all the dependent packages.OOB changesets does not allow that.
[release]prefix in the commit. This will make CI to add relevant release Git tags and publish to NPM.Patch/hotfix release flow:
hotfix-release-prepGithub actionrelease/package@versionbranch for hotfix developmenthotfix.rc.canarytag will be attached to npm packagesChangelogs
Changelogs will be generated automatically for every package for ease of tracking changes. The entries from base packages will be propagated to the dependents' changelogs.
The intended new usage for changelogs is to publish github releases only for the user-facing packages. At this time these are:
We don't need to post individual changelogs for each package this way, ensuring changes are accounted for and GitHub spam is avoided.
Sample new changelog format:
Samples versioning
create-content-sdknow hasdevDependenciesto the packages used in its samples. When sample is scaffolded,package.jsonwill be read for the appropriate versions (i.e. @sitecore-content-sdk@nextjs:1.4.0) which will be inserted into scaffolded sample.In future we can keep samples as separate packages, simplifying
create-content-sdk.Testing Details
Lots of manual testing over at https://github.com/art-alexeyenko/content-sdk
Types of changes