Skip to content

[SDK] Change the mechanism for publishing new package version #3424

Description

@dnechay

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:

  1. Implement changes and merge them as PRs to develop
  2. Create release PR and merge it to main
  3. 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:

  1. Implement changes and merge them as PRs to develop
  2. Have a release PR (as we do now)
  3. 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)
  4. Merge updated version to develop, then merge release PR to main
  5. 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

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

Status
Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions