tidelabs / tidechain Goto Github PK
View Code? Open in Web Editor NEWTidechain is the backbone of the TIDE ecosystem. Built on Substrate.
Home Page: https://tidelabs.github.io/tidechain/
License: GNU General Public License v3.0
Tidechain is the backbone of the TIDE ecosystem. Built on Substrate.
Home Page: https://tidelabs.github.io/tidechain/
License: GNU General Public License v3.0
This is the release checklist for Tidechain v0.1.4. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.4
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.3. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.3
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
There are one benchmarking machine reserved for updating the weights at
release-time. To initialise a benchmark run for each production runtime (tidechain and hertel):
git patch patchfile.patch
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.3.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.3.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.3. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.3
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.2.3. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.2.3
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.4.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.4.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.6.4. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.6.4
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.6.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.6.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.4.4. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.4.4
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.5. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.5
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.5.2. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.5.2
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.7.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.7.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.4.2. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.4.2
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.4.3. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.4.3
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.2. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.2
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
There are one benchmarking machine reserved for updating the weights at
release-time. To initialise a benchmark run for each production runtime (tidechain and hertel):
git patch patchfile.patch
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.2.2. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.2.2
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.7.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.7.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.6.1. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.6.1
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
We need to define the best use for the Election Fallback
Right now we are getting election provider failed due to ElectionError::Fallback("NoFallback.")
This is the release checklist for Tidechain v0.1.4. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.4
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.6. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.6
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.3. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.3
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.1. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.1
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
There are one benchmarking machine reserved for updating the weights at
release-time. To initialise a benchmark run for each production runtime (tidechain and hertel):
git patch patchfile.patch
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.5. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.5
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.5.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.5.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.5. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.5
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.1.6. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.6
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.5.1. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.5.1
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
The flaw in the current slippage logic is that, while it will protect the user
if the price goes against them, it will also block the trade if the price moves
in their favour.
More details in RFC 001 in Gitlab
This is the release checklist for Tidechain v0.7.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.7.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.6.3. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.6.3
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
Market
and Limit
This is the release checklist for Tidechain v0.1.4. All following
checks should be completed before publishing a new release of the
Tidechain/Hertel runtime or client. The current release candidate can be
checked out with git checkout release-v0.1.4
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Hertel validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
There are one benchmarking machine reserved for updating the weights at
release-time. To initialise a benchmark run for each production runtime (tidechain and hertel):
git patch patchfile.patch
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.6.2. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.6.2
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.2.0. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.2.0
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.2.1. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.2.1
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
This is the release checklist for Tidechain v0.4.1. All following
checks should be completed before publishing a new release of the
Tidechain/Lagoon runtime or client. The current release candidate can be
checked out with git checkout release-v0.4.1
These checks should be performed on the codebase prior to forking to a release-
candidate branch.
spec_version
has been incremented since thespec_version
or impl
must be bumped.transaction_version
if not.The following checks can be performed after we have forked off to the release-
candidate branch or started an additional release candidate branch (rc-2, rc-3, etc)
Ensure that SEMNET DevOps has run the new release on Tidechain and Lagoon validators for at least 12 hours prior to publishing the release.
Add any necessary assets to the release. They should include:
The release notes should list:
The release notes may also list:
A runtime upgrade must bump the spec number. This may follow a pattern with the
client release (e.g. runtime v12 corresponds to v0.8.12, even if the current
runtime is not v11).
Any previous on_runtime_upgrade
functions from old upgrades must be removed
to prevent them from executing a second time. The on_runtime_upgrade
function
can be found in runtime/src/lib.rs
.
Ensure that any migrations that are required due to storage or logic changes
are included in the on_runtime_upgrade
function of the appropriate pallets.
Offline signing libraries depend on a consistent ordering of call indices and
functions. Compare the metadata of the current and new runtimes and ensure that
the module index, call index
tuples map to the same set of functions. In case
of a breaking change, increase transaction_version
.
To verify the order has not changed, you may manually start the following Github Action. It takes around a minute to run and will produce the report as artifact you need to manually check.
The things to look for in the output are lines like:
[Identity] idx 28 -> 25 (calls 15)
- indicates the index for Identity
has changed[+] Society, Recovery
- indicates the new version includes 2 additional modules/pallets.[Identity] idx 25 (calls 15)
Note: Adding new functions to the runtime does not constitute a breaking change
as long as the indexes did not change.
The runtime contains proxy filters that map proxy types to allowable calls. If
the new runtime contains any new calls, verify that the proxy filters are up to
date to include them.
Use the bench-bot on github
to run the benchmarks.
Ensure that a release of Tidechain Client contains any new types or
interfaces necessary to interact with the new runtime.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.