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
An idea is to publish the artifact containing the specfile bound by the spec version number.
This would likely have a few other implications, like
... verifying that the spec file is equivalent (not syntactically, but semantically) to what would be published and not failing the build if the file already exists
... splitting out a verify- variant of this that would be run before publishing any other artifacts, to ensure that what is about to be released is compatible with the specfile that was previously published
This is motivated by attempting to increase confidence in older clients. One of the benefits of generating client libraries in a codebase is confidence around whether the client classes are compatible with dependent libraries, since they are all compiled at the same time.
This is lessened when clients (or servers) are needlessly rolled due to the perception of an upgrade, when in reality it's just the same version of the specfile being published again and again with different version numbers.
Decreasing churn and increasing confidence in "I depended on this version of the wire protocol" instead of "I depended on whatever version of the wire protocol server xyz was compiled against" is the intent behind this issue
The text was updated successfully, but these errors were encountered:
An idea is to publish the artifact containing the specfile bound by the spec version number.
This would likely have a few other implications, like
verify-
variant of this that would be run before publishing any other artifacts, to ensure that what is about to be released is compatible with the specfile that was previously publishedThis is motivated by attempting to increase confidence in older clients. One of the benefits of generating client libraries in a codebase is confidence around whether the client classes are compatible with dependent libraries, since they are all compiled at the same time.
This is lessened when clients (or servers) are needlessly rolled due to the perception of an upgrade, when in reality it's just the same version of the specfile being published again and again with different version numbers.
Decreasing churn and increasing confidence in "I depended on this version of the wire protocol" instead of "I depended on whatever version of the wire protocol server xyz was compiled against" is the intent behind this issue
The text was updated successfully, but these errors were encountered: