Lisk-sdk: Clean the version and minVersion config from all config files

[nazarhussain]

Expected behavior

version of the lisk itself is identifier for the software so should not be configureable. So instead version inside package.json is the right place to specify the version of the current software package.

Also the minVersion should be set as constant value which is shipped along with the build of the system. It should not be configurable value.

Actual behavior

Currently version and minVersion are both set in config.json

Which version(s) does this affect? (Environment, OS, etc...)

1.0.x

[nazarhussain]

Based on discussion with @MaciejBaj we will keep version and minVersion both in package.json. As both are the attributes of the software that we are shipping.

[nazarhussain]

So our package.json file will look something like this:

{
    "name": "lisk",
    "version": "1.1.0",
        "lisk": {
              "minVersion": "1.0.0"
         }
.....
.....
.....

Its a good practice to have one root level key for all custom attributes in package.json

[willclarktech]

I suggest using a range of compatibility, similar to the engines field and dependencies etc: https://docs.npmjs.com/files/package.json#engines

[nazarhussain]

@willclarktech Nice suggestion. We can rename minVersion to compatibility and use this format > =1.0.0 or later when needed >=1.0.0 <2.0.0.

But we need to see if max version range really is a foresee feature in near future. If we just need a to specify range on just minVersion e.g. ~1.1.0 we can do it only with minVersion check.

@MaciejBaj Your input on this.

[4miners]

So we're currently using minVersion mainly for delaing with hard forks - when we want to cut down the _old_ (incompatible) part of the network. But that is not really a proper way to deal with that, for example we have version property in block object that can be used in similar way. Taking all that into account _range of compatibility_ idea makes sense.

[nazarhussain]

In theory we are using minVersion to just check, down to which version our software is compatible to. And this compatibility information is only used during peer handshake. We are not using this compatibility information anywhere else e.g. block verification. So we make assumption here that a peer running with older version will never appear in network, so any block forged by that version will also not appear in chain.

Yes probably we should move that logic into block verification as well as in peer connection. But if we look at improving block verification for chain security it's a different research topic. Must be thought separately.

[MaciejBaj]

@nazarhussain good point. I am opting for sticking with the current naming system - use minVersion, but move it to package.json.