Is your feature request related to a problem? Please describe.
When sdk is published - it has human-protocol/core version specified as x (analogue of *) which creates different issues like:
- when you install some specific version of
sdk, e.g. 3.0.8, you still get latest version of core, not one that is supposed to work
- once you have
sdk installed, core package dependency is "locked" and not getting updated when you bump sdk
In order to solve the above issues, we have to use the exact version of core package in sdk, which means changing "@human-protocol/core": "workspace:x" to "@human-protocol/core": "workspace:*" in package.json of sdk, so when yarn pack the package it will resolve workspace reference to exact core version from its package.json (check docs for details). In order to implement such change - we have to keep version field in package.json updated for all publishable packages, but such change is going to break the CI/CD process we have now.
Describe the solution you'd like
Right now our CD process for human-protocol/core and human-protocol/sdk process looks like:
- Implement changes and merge them as PRs to
develop
- Create release PR and merge it to
main
- Create a new GitHub Release w/ proper version tag that triggers
core and sdk to be published with the same version.
The proposal is to change it to the next one:
- Implement changes and merge them as PRs to
develop
- Have a release PR (as we do now)
- When preparing a release, revisit all changes that are made for all publishable packages and bump
version field in their package.json via separate PR (so we can review if the version is correct)
- Merge updated version to
develop, then merge release PR to main
- Once you have packages with proper versions merged to
main branch - it should trigger GitHub action that will publish all necessary packages in the proper order (e.g. sdk depends on core, so we have to make sure that core is published first`)
Such workflow should be retryable, i.e. if check should present on "if version is already published/no changes - do nothing".
Describe alternatives you've considered
We considered using an automated tools, e.g. semantic-release, but agreed that it is an overhead for now and we can think about it in case we publish new package version more often and simple but a bit manual process become too complicated.
Additional context
PRs that fixed broken dependency resolution and have some more details: #3419, #3422
Is your feature request related to a problem? Please describe.
When
sdkis published - it hashuman-protocol/coreversion specified asx(analogue of*) which creates different issues like:sdk, e.g. 3.0.8, you still get latest version of core, not one that is supposed to worksdkinstalled,corepackage dependency is "locked" and not getting updated when you bumpsdkIn order to solve the above issues, we have to use the exact version of
corepackage insdk, which means changing"@human-protocol/core": "workspace:x"to"@human-protocol/core": "workspace:*"inpackage.jsonofsdk, so whenyarn packthe package it will resolve workspace reference to exactcoreversion from itspackage.json(check docs for details). In order to implement such change - we have to keepversionfield inpackage.jsonupdated for all publishable packages, but such change is going to break the CI/CD process we have now.Describe the solution you'd like
Right now our CD process for
human-protocol/coreandhuman-protocol/sdkprocess looks like:developmaincoreandsdkto be published with the same version.The proposal is to change it to the next one:
developversionfield in theirpackage.jsonvia separate PR (so we can review if the version is correct)develop, then merge release PR tomainmainbranch - it should trigger GitHub action that will publish all necessary packages in the proper order (e.g.sdkdepends oncore, so we have to make sure thatcoreis published first`)Such workflow should be retryable, i.e. if check should present on "if version is already published/no changes - do nothing".
Describe alternatives you've considered
We considered using an automated tools, e.g.
semantic-release, but agreed that it is an overhead for now and we can think about it in case we publish new package version more often and simple but a bit manual process become too complicated.Additional context
PRs that fixed broken dependency resolution and have some more details: #3419, #3422