Consider removing OPTIONS version negotiation

[thekaveman]

Is your feature request related to a problem? Please describe.

Back when the version header was specified, we included the notion of version negotiation via OPTIONS requests. See #293 for implementation and conversation history.

In my 2 years of ingesting Provider data at the City of Santa Monica, we never had a need for version negotiation. A follow-up comment on #293 indicates that this feature complicates the Provider implementation and versioning of MDS, especially given we are just now entering 1.0 territory:

... in the case of MDS, i think it's very clear that when we publish a new version, we want to deprecate the old, and in order to encourage the deprecation of the old to be done in a timely manner, we shouldn't allow negotiations for older versions after a short amount of time passes the release of a major version.

... if a client can accept an updated version of MDS Provider, i don't see a case where they would want to accept the older version, which would happen via OPTIONS content negotiation

Describe the solution you'd like

I'm opening this issue to discuss the possibility of removing OPTIONS version negotiation from the spec. I'm especially curious to hear from anyone that has used this feature:

• if you are a Provider that has implemented this feature, how easy/complicated was this implementation? Do you see consumers using version negotiation? If so, how many/which versions are being negotiated for?
• if you are a data consumer that has implemented this feature, how easy/complicated was this implementation? Why do you use version negotiation? How many/which versions are you negotiating for?

If possible, I'd like to include this in 1.0.0 since we're making a number of breaking changes, including to the version header itself.

Is this a breaking change

• Yes, breaking

Impacted Spec

For which spec is this feature being requested?

• agency
• policy
• provider

Describe alternatives you've considered

Do nothing, leave the feature specified as-is.

[thekaveman]

Draft PR to look at this in context: lacuna-tech#12

Submitted against the Reconciliation PR/branch as much has been changed/reorganized in this PR and targeting it will help avoid conflicts. I marked as Draft for now as there hasn't yet been much discussion, but we'll bring it up on the next Provider call.

[schnuerle]

Even if this isn't used now, do you see the need for this to be potentially used more in the future as there are more releases out there that people are supporting? Would like anyone's thoughts on this, but otherwise this change looks good to simplify the spec.

[thekaveman]

Discussion on 6/18: it sounds like this hasn't been widely implemented in the field and we are OK with removing.

Important to note that the ability to request different versions of the spec is not being changed, we're just simplifying and saying that a human should be making that decision each time vs. trying to automate discovery and agreement of versions. It sounds like this is the more general practice in the field today anyway.

Once #506 is merged, I'll submit a new PR with the same changes as the linked PR, into the MDS repo.

[marie-x]

Sounds good to me

[schnuerle]

Completed with #536.