One of the few commands that ClipboardLAN protocol includes is the VERSION command. VERSION works like this:
> VERSION 101 Current protocol version follows 2.0.0
This is deadly simple. I could even dismiss the status response, but I put it because I might change my mind so as not to allow this request to be processed if it comes from an unlogged client (currently, it answers unlogged client requests).
However, there is something not that simple: versioning. I deliberate about what versioning scheme I should use. I thought the major.minor.build scheme would fit for this project. Why did I choose this one instead of the others? Because I plan to release often.
In spite of not existing something as THE SOFTWARE VERSIONING METHOD, I think this is the best approach for a project like this. I thought that major version number will represent the version of the protocol, so every compatible ClipboardLAN release will have version 2.x.x. The minor build will increment each time there are major changes in the UI and the build number is just the build by the moment.
Summing up:
- Two different instances could work smoothly if the share the same major number. 2.x.x and 2.y.y works!
- The change between 2.0.x and 2.1.y is an improved UI.
- Build number is not necessarily significant by the moment, but it is there because we might need it someday to specify something meaningful.
