At the moment, https://sovrin.slack.com/archives/C5FJY7F1Q/p1540391559000100, for a validator to join a Sovrin Network (i.e. TestNet, MainNet), its administrator must know the version of Indy that the network is running/supports and also the package version for all the apt packages that are relied upon by that version.
For example, for the v1.6.73, upgrade, this was the install string we were required to use:
This is a bit unwieldy. So this issue is to track the work of being able to point at a specific version of either the Sovrin or Indy-Node packages and get all the correctly depended upon packages. However, along these same lines, there's another requirement here:
For those users who are not currently on the Sovrin Slack, which may be quite a few, it can be difficult to tell if you're going to get the correct version of Indy to join, say, the TestNet, if you just execute:
Or maybe even just:
There are already in place, master and stable branches in the Sovrin/Indy apt repository, so my proposal is that there be two more branches: testnet and mainnet. These branches would always point to the versions of the packages that a person needs to install to join the corresponding network.
These fixes help address the situations where:
- An Sovrin Validator administrator is trying to follow the latest instructions on deploying their validator, and the packages that they install are incompatible with what's running on the network they would like to join (note that they must join the TestNet before being allowed on the MainNet, so the when the versions are different, this is problematic).
- The MainNet and TestNet are running different versions, as they are at the time of writing, without having to specify a long list of package versions, we can just use apt's built-in functionality for this situation to make it effortless to join any/either network.
- Automated tools are being built to build, for example, Docker images, or virtual machine appliances/images, and maintaining the list of packages is a long, complicated process. Instead, what if the build engine could just use a branch of the apt repo and automatically be ensured compatibility with the desired network.
I'm not proposing that we remove or forget the stable, master, or RC branches – these definitely have their purpose as is already demonstrated by the community. I just find that the situation comes up a lot on Sovrin Slack and it could be ameliorated by this already existing feature of apt.
I'm aware that a process already exists in which the Trustees push a transaction to the config ledger or poor ledger that causes the validator nodes to automatically update in place. That's fine. When that is executed would be a good time to update the pointer on that network to point at the version that will be installed when the upgrade is complete. A Steward (or maybe even a trust anchor) who is not attached to the network at the time of the transaction has no idea what version they need to use in order to even read these transactions though, and we definitely saw the transaction structure change with recent upgrades, and I am sure that will happen again.