Version scheme should be changed

[GaticusHax]

A different method for storing and relaying the supported NMS version should be devised so that the project versions are not tied to it.

This is a bit tricky as it may be confusing for users for a little while, but particularly now that the API and CLI has been split, the versioning for those files should better reflect their functionality instead of the NMS version they correspond to.

The CLI for example, is no longer tied to the NMS version. It will be possible to use different versions of the CLI with the same dll for example. When it does change, the version should properly reflect that.

When the API is ready for use in external projects, this version problem will be even worse since changes to the API will not correspond to any NMS version.

We should be able to use a semantic version scheme, which provides indications to the severity of the changes in the distributables.

When we do this, the version should probably jump to v2, to make it clear that the versions no long directly correspond to the NMS version. v2 would also be a good place to set a milestone for having the API ready for external use as that is a major change and would be appropriate for a MAJOR version increment.

[monkeyman192]

So we made the jump to version 2... Can this be closed or are there still issues to deal with?

[GaticusHax]

wait, wat? we did? lol