Advantage of storj-up is that you can quickly change between different versions and you can also run a mixed state with half the nodes running old code and the other half running latest code.
You need to checkout (or pull) the new changes from the upstream and rebuild.
However, I think it could not be build in Release mode, since storj-sim is not for production.
In would be possible to do that but also it would change the default config for all binaries. So the satellite would expect to talk to 95 storagenodes instead of 10. → development build is correct here.
That will not solve your problem. The difference between production defaults and test defaults is bigger than just the node count. I don’t understand why you even want to run a test network with release defaults. That is outside the scope of a test network.
no. Some parameters across all codebase has several defaults, for example,
When you use <service> setup --defaults dev (or <service> run --defaults dev), it will pre-configure all default values taken from devDefault values.
See:
$ satellite setup --help | grep "defaults"
--defaults string determines which set of configuration defaults to use. can either be 'dev' or 'release' (default "dev")
So you need to examine code for each default value marked accordingly selected defaults.
It should use the release defaults, but will it work as in production - I do not know, as I said.
I only know that storj-sim is not designed for production use.