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
When rustls-ffi started, it was producing incompatible API changes in the C API at a faster rate than rustls itself, so I chose an independent versioning scheme. Now the rate of API changes in rustls has picked up, and the rate of API changes in rustls-ffi has slowed down, so it makes more sense to give them the same versioning scheme. So for instance, the next release of rustls-ffi would be 0.23.1, and it would build against rustls 0.23.1. WDYT @cpu ?
The text was updated successfully, but these errors were encountered:
Is the intent that we would match the most significant component only, but would release/version independently in the less significant components? E.g. a rustls-ffi 0.23.x release would be implied to be using Rustls 0.23.x, but we could release a rustls-ffi 0.23.1 for a bugfix that would be independent from a rustls 0.23.1?
In general I'm supportive of the idea and just want to make sure I understand the finer points w.r.t. what would happen if we need to publish additional rustls-ffi specific work after a breaking rustls update.
When rustls-ffi started, it was producing incompatible API changes in the C API at a faster rate than rustls itself, so I chose an independent versioning scheme. Now the rate of API changes in rustls has picked up, and the rate of API changes in rustls-ffi has slowed down, so it makes more sense to give them the same versioning scheme. So for instance, the next release of rustls-ffi would be 0.23.1, and it would build against rustls 0.23.1. WDYT @cpu ?
The text was updated successfully, but these errors were encountered: