Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the release process for docs #1668

Merged
merged 1 commit into from
Dec 4, 2024
Merged

Update the release process for docs #1668

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 28 additions & 4 deletions RELEASE_PROCESS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,35 @@
3. create a release on Github with the changelog details and mark it pre-release
4. Update all the package.json files to define a new unstable version, eg 0.7.1-unstable and regen package-lock.json (PR 2)

## Docs
1. from the gh-pages branch, edit the docs in vNext to point to the next caliper versions (eg 0.7.0 and 0.7.1-unstable etc)
2. update docs.json with the new caliper version and run the script bump-docs.js (PR 3)

## Caliper benchmarks
1. Create a release in caliper-benchmarks corresponding to the new release, eg 0.7.0

## Docs

There are 2 aspects here
1. update an existing version
2. publishing a new version and make it the default

One final point to note is that although the `mike` tool manages all the documentation we still have to maintain the /assets/img directory. This is required for Caliper 0.6.0 to find a hyperledger logo in it's report.html template.
The old documentation is also currently kept in the `.OldDocs` directory

### Updating an existing version

1. create branch newdocs based off of gh-pages
2. switch to branch that contains the doc changes and change to docs directory
3. run `mike deploy -b newdocs <version>` (note the commit won't be signed) - specify appropriate version for <version>, eg `0.6.0`
4. switch to newdocs and amend the last commit to sign it
5. submit pr of newdocs to gh-pages

## Publishing a new version

1. create branch newdocs
2. switch to branch that contains the doc changes and change to docs directory
3. run `mike deploy -b newdocs <version>` (note the commit won't be signed) - specify appropriate version for <version>, eg `0.7.0`
4. switch to newdocs and amend the last commit to sign it
5. switch back to branch that contains the doc changes
6. run `mike set-default <version> -b newdocs` (note the commit won't be signed) - specify same version used for the deploy
7. switch to newdocs and amend the last commit to sign it
8. submit pr of newdocs to gh-pages

(see https://stackoverflow.com/questions/13043357/git-sign-off-previous-commits for a way to sign multiple commits in the future)
Loading