feature idea: versioning

[jtmarmon]

It would be cool to have schemas have optional versioning, so if I decide to make breaking changes to an API, the schema can still be coerced properly for clients requesting the old version. Not sure exactly what this would look like but I think it would be quite handy.

[w01fe]

Thanks for the request. I'm not sure it makes sense for versioning to be built into schema, but potentially can be a layer built on top. For example, we've thought about (but not yet implemented) extensions to fnhouse that allow you to declare different coercions for different data versions, which could transparently manage the coercion to the latest version for you. Is this the sort of thing you're looking for?

[jtmarmon]

Yep coercion is the main consideration here. Why would this be a feature in fnhouse, though? Isn't coercion a function of the schema library?

I definitely think some kind of integration with fnhouse would be useful - maybe if API versioning was added to fnhouse you could tie the coercion functions to the API versions

[w01fe]

I suppose you're right that versioning could be useful outside of fnhouse, but I still think it's probably possible to do as a layer on top of the existing primitives. It seems like the tricky questions might revolve around nesting, and whether subschemas are versioned together or independently. If there are concrete proposals, we'd love to listen/look at them and consider for inclusion. Thanks!