doc: document protocol versioning policy

[aqrln]

In order to communicate with developers of alternative implementations and be reasonable about compatibility, we need to assign versions to the protocol too. This PR documents the protocol versioning policy (see details in the changed file).

According to this proposal, e.g., the current version of the protocol is 0.5 and the next one, if #54 lands, is 0.7.

@tshemsedinov, @belochub, do you agree with this proposal or you have other ideas about how we must assign versions to the protocol?

[belochub]

Probably missing "be" after "will".

[aqrln]

Thanks, I will update the commit in a moment.

[belochub]

LGTM

[aqrln]

@tshemsedinov still waiting for you to review the proposal.

[tshemsedinov]

Does it mean that protocol version will be equal to package version after 1.x?

[aqrln]

@tshemsedinov to the first version of the package that introduced the changes found in this version of protocol, to be exact. Version 1.0.0 is a special one in one case: if package version 1.0 introduces no changes to protocol since, for example, version 0.9, then as soon as package version 1.0 is released, the protocol version is bumped to 1.0 anyway, just the specification is identical for protocol versions 0.9 and 1.0. The reason is that when we release the first stable version of the package, we want the protocol version to indicate that it is stable too, and vice versa, before until we have released the first stable version of the package, we cannot guarantee that the protocol is already stable since some changes in functionality require changes in the protocol

[aqrln]

@tshemsedinov alternatively, the protocol can be semantically versioned by itself, independently of this package, as soon as we reach 1.0.0.

[belochub]

@aqrln, in my opinion, alternative option to version protocol by itself is better if we are going to create formal specification of the protocol (which I hope we will).

[aqrln]

@belochub yeah, after some thinking about it I think I would prefer the mixed approach:

1. Before we reach 1.0, versions of the protocol are better to be bound to package versions. It would be nice to have it versioned independently, but it's too late to do it, since we haven't been versioning it from the beginning and we have made changes to the specification multiple times. I would not opt for backdating with assigning versions to what was done in the past.

2. As soon as we reach 1.0 in the package, we take this as the starting point, assign the version 1.0 to the protocol and have its specification versioned with semver independently of the package.

@tshemsedinov, what do you think about it?

[tshemsedinov]

Great

[aqrln]

I've just updated the commit so that the document reflects the consensus of the discussion.

@belochub, @tshemsedinov, please check it out and say if it LGTY.

[belochub]

Maybe avoid phrase "specific specification"?

[aqrln]

@belochub reworded the sentence for clarity and to be more stylistically correct.

[belochub]

LGTM

[aqrln]

Landed in 51c763f.