Match node version with tag version

[ghost]

Description

Matches the node package version to latest tag version of the repo. Also unifies other crates to a single version which is defined in the root workspace Cargo.toml.

Substrate has a build script that reads CARGO_PKG_VERSION(https://github.com/paritytech/polkadot-sdk/blob/polkadot-v1.1.0/substrate/utils/build-script-utils/src/version.rs#L52). Then it saves the version as SUBSTRATE_CLI_IMPL_VERSION and it is returned by SubstrateCli::impl_version() (node --version)

What it means?

In the future, every time we create a release, we need to bump the version in the workspace Cargo.toml to the tag version

Other notes

polkadot recently removed dependency of node version to the crate version. There were also some issues about non-deterministic results when deriving node version from crate. Node's version is now included in compile-time, i.e hard-coded as constant. Idk if we should follow the suite, but could be evaluated during an upgrade of dependencies
paritytech/polkadot-sdk#1495

Result

laos % ./target/release/laos-ownership --version
laos-ownership 0.9.0-443f4c47bf8

[magecnion]

I suggest that if no any automazation is added at least add some wiki or doc where we specify the steps to release+upgrade emphasising the fact that we need to keep the same value from tag within Cargo.toml

[asiniscalchi]

/ask what if the tag does not follow the standard v*.. for example alpha-test-version

[github-actions]

Question: what if the tag does not follow the standard v*.. for example alpha-test-version?

Answer:
The current implementation in the PR assumes that the tags follow the semantic versioning format with a 'v' prefix (v*..). If a tag does not follow this format, for example alpha-test-version, the script in the GitHub workflow file (build.yml) would not be able to correctly extract and compare the version numbers.

The script uses the git describe --tags command to get the latest tag and then removes the 'v' prefix using sed -E 's/v(.*)/\1/'. If the tag is something like alpha-test-version, this operation would not correctly extract a version number.

To handle non-standard version tags, the script would need to be updated to accommodate the specific format of these tags. This could involve using a more complex regular expression or a different method of parsing the tag string. However, it's generally recommended to stick to a standard versioning scheme (like semantic versioning) for consistency and ease of use.

[asiniscalchi]

/ask what if we don't use release/v* branches ?

[github-actions]

Question: what if we don't use release/v* branches ?

Answer:
If you don't use release/v* branches, the check for the branch type in the build.yml file will not work as expected. This check is specifically looking for branches that start with release/v to determine if the PR is releasing a new version.

In the current setup, if the branch is of type release/v*, it checks if the version in Cargo.toml is different from the latest tag. If it's not, it throws an error because it expects a version change for a release.

If the branch is not of type release/v*, it checks if the version in Cargo.toml matches the latest tag. If it doesn't, it throws an error because it expects the version to match the latest tag for non-release branches.

If you don't use release/v* branches, you would need to modify this check to suit your branch naming conventions or versioning strategy. For example, you could check for a different branch prefix, or remove the branch type check altogether if it's not relevant to your workflow.

[ghost]

/ask what if we don't use release/v* branches ?

I used it since this pattern is also hard-coded here

[ghost]

/ask what if the tag does not follow the standard v*.. for example alpha-test-version

we might not use semver?

[asiniscalchi]

/ask what if the tag does not follow the standard v*.. for example alpha-test-version

we might not use semver?

git tag does not use semver

[ghost]

/ask what if the tag does not follow the standard v*.. for example alpha-test-version

we might not use semver?

git tag does not use semver

I mean, we make the releases and we choose how to version it, no?

[asiniscalchi]

/ask what if we don't use release/v* branches ?

I used it since this pattern is also hard-coded here

In our workflow, release/v* branches are specifically utilized for creating hotfixes. For instance, when we need to release v0.4.1, we branch off from the v0.4.0 tag to create a release/v0.4 branch. This branch is dedicated to applying necessary changes for v0.4.1. Additionally, the same release/v0.4 branch is used for developing all subsequent v0.4.* hotfixes. Generally, we don't create release branches unless it's for this specific purpose of hotfixing.

[asiniscalchi]

/ask is it possible to create a workflow in git-action which is triggered on tag ?

[github-actions]

Question: is it possible to create a workflow in git-action which is triggered on tag ?

Answer:
Yes, it is possible to create a workflow in GitHub Actions that is triggered on a tag. You can use the create event type and then filter for tags. Here's an example:

on:
  create:
    tags:
      - v*

In this example, the workflow will be triggered whenever a tag starting with 'v' is created. You can modify the tag pattern to suit your needs.

For example, if you want to trigger the workflow for any tag, you can simply use '*':

on:
  create:
    tags:
      - '*'

This will trigger the workflow whenever any tag is created.

Remember to replace the on: section in your current workflow file with the above code to set up the tag trigger.

[asiniscalchi]

Question: is it possible to create a workflow in git-action which is triggered on tag ?

Answer: Yes, it is possible to create a workflow in GitHub Actions that is triggered on a tag. You can use the create event type and then filter for tags. Here's an example:

on:
  create:
    tags:
      - v*

In this example, the workflow will be triggered whenever a tag starting with 'v' is created. You can modify the tag pattern to suit your needs.

For example, if you want to trigger the workflow for any tag, you can simply use '*':

on:
  create:
    tags:
      - '*'

This will trigger the workflow whenever any tag is created.

Remember to replace the on: section in your current workflow file with the above code to set up the tag trigger.

this could be a path leading to a more solid solution ( maybe )

[magecnion]

I think it would be nice also to check that the runtime version is aligned to tag version. There a way to get the version from the wasm.

[ghost]

I think it would be nice also to check that the runtime version is aligned to tag version. There a way to get the version from the wasm.

would be out of the scope of the PR/story. maybe we can add in the future sprints