Use the same (or similar, or very different) version numbers for smart contracts and Python packages.

[pirapira]

Currently the Solidity files contain one version number (say, 0.7.0) and the Python package has another version number (say, v0.11.0). This confuses some people. Maybe we should use the same version or closer version numbers. This issue keeps track of

• deciding
  a. combine these two version numbers into one
  b. bump smart contract versions to the package version
  c. don't change the current scheme.
  d. make the contract version numbers look very different from tha Python package versions
• implementing the change if decided.

[pirapira]

I'll come up with the advantage of having two different version numbers.

[pirapira]

advantage of keeping different contract numbers

With the current set up, it's possible to deploy a new version of one smart contract and still keep using the old deployment of another smart contract. If we synchronize the package version and the contract version, every new PyPI release must contain new deployements of every contract. That's unreasonable for the user.

[pirapira]

@karlb has an idea:

We could also bump the contract version number to the current python package version each time we do a deploy.

[rakanalh]

I think the argument makes sense as the package version could be different than the solidity code version... i see two approaches:
Prequisite:

Then:

1. Either bring the both versions to the same number and bump both numbers when the package is updated.
2. Document why we have 2 versions for a package

I guess number 2 would be the faster approach as you can direct people towards the documentation if asked about this topic again :)

[hackaugusto]

advantage of keeping different contract numbers

With the current set up, it's possible to deploy a new version of one smart contract and still keep using the old deployment of another smart contract. If we synchronize the package version and the contract version, every new PyPI release must contain new deployements of every contract. That's unreasonable for the user.

This is the reason for having different versions, also please make all deployed versions easily available.

[pirapira]

@karlb came to me and explained a scheme:

• all new deployments get at least a minor upgrade in contracts_version so the new contracts_version looks very similar to the next Python package version.
• all Python-only upgrades get a patch upgrade in the package version

I think this works.

There was a counter argument with which @hackaugusto agreed. The argument is not valid anymore, because different contracts_versions already share the same SecretRegistry deployment.

[pirapira]

#1303 implements this change.