Remove protocol versions from implementations, in part or entirely

[raucao]

Since nobody used protocol versions much in at least the last few years, I'd like to propose to remove the official scheme, or at least make it less prominent. Right now, the README of this repo is almost entirely about this topic, even though it's mostly irrelevant at this point.

We could remove the versioning partially, in that we do keep the scheme and implementations, but we don't tell people to update their servers and/or clients every 6 months just to set a new version number. Instead, we could recommend to do this only when there's a breaking change in a new protocol version.

Alternatively, we could rely solely on feature data in the Webfinger response for clients to know exactly which features or feature versions are supported, without relying on generic protocol versions. We already do this for some features, like e.g. range requests. I think this is the way to go, because it's already future-proof for remoteStorage extensions that aren't part of the base RFC.

@michielbdejong @fkooman WDYT?

[michielbdejong]

Good point! The scheduled versions were copied from Ubuntu but we haven't had any breaking changes since version 12 which was over 3 years ago.

[DougReeder]

I concur that we should only have new version when there's a change, and devote minimal space to versioning.

[michielbdejong]

OK, we can also just set the version to 1.0 in the next internet draft, that decouples it form the 6-month cadence that internet drafts have, and also feels like a nice milestone.

[raucao]

Seems like a good idea!

I'm wondering if this can create problems in case the protocol undergoes breaking changes (outside of our control) during the RFC process. Then again, it could just end up as version 2.0 afterwards, if that's the case. So then this would actually help with that situation, too.