Establish release guidelines and semantic versioning documentation

[kzndotsh]

This issue is to discuss our plans for release structuring and version numbering.

[scottc943]

https://semver.org - we could just do a minor version per PR by default unless it is prepended by like [FIX] then do a patch. For major versions it's hardly going to "happen", but if we make a big change that doesn't work in version 1.X.X then we should go to a next version similar to an api.

Are features breaking changes? Some could argue for it. Features added in X.1.0 won't be the same as 1.0.0 therefore tux 1.0 could not run the "jail" command but tux 2.0 would

Maybe features are the major version change here

[electron271]

x.y.z
x - breaking changes which require hosters to do large changes to their infrastructure (e.g migrating platforms)
y - changes that may require some configuration on the hosters part
z - changes that require little to no changes on the hosters part

[kzndotsh]

x.y.z

x - breaking changes which require hosters to do large changes to their infrastructure (e.g migrating platforms)

y - changes that may require some configuration on the hosters part

z - changes that require little to no changes on the hosters part

Do our releases only take into consideration self hosters and contributors? What about server owners that adopt our main bot if we ever go public? e.g. we change all the arguments for a command group.

[Atmois]

i think we should do x.y.z and have a list of guidelines what counts as x and y and everything else is z