You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While reviewing the release branch in #261, I noticed that we have an awful lot of viceroy-lib exposed as public, including session methods like insert_pending_request() and types like AsyncItem. It is very difficult to imagine these being useful to anyone outside of viceroy-lib itself, and so their presence in the public interface is a semver trap that I don't think yields us much benefit.
In addition, we have types like Error which are legitimately useful by library clients, but that are missing defensive measures like #[non_exhaustive] to prevent breakage via adding variants.
I think we should either:
reduce our exposure to semver traps by
making the public interface of viceroy-lib smaller, and
using mitigations like #[non_exhaustive] to make the remaining public interface more forwards-compatible
or adopt a wasmtime-like strategy where every non-bugfix release is a major semver bump, and we just don't worry about what we expose
I don't have a great sense of how many clients of viceroy-lib there are other than viceroy-cli, so maybe folks could weigh in here if either of these changes would impact you or others you're aware of?
The text was updated successfully, but these errors were encountered:
While reviewing the release branch in #261, I noticed that we have an awful lot of
viceroy-lib
exposed as public, including session methods like insert_pending_request() and types likeAsyncItem
. It is very difficult to imagine these being useful to anyone outside ofviceroy-lib
itself, and so their presence in the public interface is a semver trap that I don't think yields us much benefit.In addition, we have types like
Error
which are legitimately useful by library clients, but that are missing defensive measures like#[non_exhaustive]
to prevent breakage via adding variants.I think we should either:
viceroy-lib
smaller, and#[non_exhaustive]
to make the remaining public interface more forwards-compatibleI don't have a great sense of how many clients of
viceroy-lib
there are other thanviceroy-cli
, so maybe folks could weigh in here if either of these changes would impact you or others you're aware of?The text was updated successfully, but these errors were encountered: