The following artifacts are created as a result of releasing the Hyperledger Fabric Gateway SDKs:
- npm modules
- Java libraries
The following tasks are required before releasing:
- Update version numbers if required (see below for details)
- Update test, sample, and docs files to match the new version if it was updated
Creating a GitHub release on the releases page will trigger the build to publish the new release.
When drafting the release, create a new tag for the new version (with a v
prefix), e.g. vX.Y.Z
See previous releases for examples of the title and description.
The automated build process currently only publishes the Java SDK to Hyperledger's repository.
To publish it to the Central Repository requires an additional manual step (tbc):
mvn deploy:deploy-file -DpomFile=<path-to-pom> \
-Dfile=<path-to-file> \
-DrepositoryId=<id-to-map-on-server-section-of-settings.xml> \
-Durl=<url-of-the-repository-to-deploy>
The following tasks are required after releasing:
- Update version numbers to the next point release (see below for details)
- Update test, sample, and docs files to match the new version
The Hyperledger Fabric Gateway client APIs follow the Go module version numbering system
The following files need to be modified when updating the version number, and these are checked by the build process to ensure they match a tagged release:
- The
GATEWAY_VERSION
variable inci/azure-pipelines.yml
- The
version
element injava/pom.xml
- The
version
property innode/package.json
Note: there is no file to update for the Go SDK, which is versioned by the release tag.
When updating the major version beyond version 1, Go modules require a new module path, e.g. version 2 would require a new v2
directory containing the new Go module code. This is a very disruptive change therefore any incompatible changes which would require a major version change should be avoided if at all possible.
See Publishing breaking API changes for more details.