Separate abstractions into own crate?

[ionut-arm]

I've been wondering a lot whether the abstractions module in the tss-esapi crate should be moved to a separate crate. My reason for the split is to not keep the two joined at the hip, and have them move at different speeds - at the moment if one wants to break something in the abstractions API, that also breaks the crate API (obviously).

This would come with a few new problems: all current users who make use of abstractions would have to move to the new crate and most likely change imports and such. The new crate would have to re-export the entire tss-esapi crate so users can work with the correct version of that API easily. It'd also mean that users won't get any updates to the tss-esapi "root" crate immediately.

Another approach would be to just put warnings in the README and docs that the abstraction module is not restricted to semantic versioning between tss-esapi releases (for now), and we can break it when we need to.

Thoughts?

[ionut-arm]

Oh, another option: we can also segregate the abstractions stuff behind a feature. This would help us with minimizing the number of dependencies needed if you only want to work with the "core" Context stuff.

[Superhepper]

hrmm yeah this is not easy.

I like the idea of having abstractions as a feature though that does not solve the problem with breaking an API in abstraction also breaks the core crate API.