[QST] What is API version compatibility?

[ZzEeKkAa]

I want to pin cutlass version that can work with my project, but could not find if cutlass follows semantic version. Right now project requires cutlass 3.5.1. Is it safe to have >=3.5.1;<4.0.0 restriction, or it should be >=3.5.1;<3.6.0?

[hwu36]

>=3.5.1;<4.0.0 should be good.

Our api will stay stable until we bump to 4.x. During 3.x time, we might only make some minor api changes.

[thakkarV]

What Haicheng said is far, but please also note that we don't strictly follow semver and have broken compatibility for minor internal methods here and there before. Pretty much anything not at the device layer abstraction doesn't promise 100% stability. That said, between minor version, we try our best to be nice and not break users too much even for abstractions below the device layer

[ankutalev]

What Haicheng said is far, but please also note that we don't strictly follow semver and have broken compatibility for minor internal methods here and there before. Pretty much anything not at the device layer abstraction doesn't promise 100% stability. That said, between minor version, we try our best to be nice and not break users too much even for abstractions below the device layer

Should I interpret this comment as answer to #2009 and #2010 ?

edit. Seems like no, because you mean only internal methods

[thakkarV]

I think fall in the same category as they are not device layer interfaces. 2009 is a fix more than breakage, since those operations only support saturating FMAs, so removing those is actually fixing the contract. 2010 is a regression if is breaks the user facing EVT API, but at a glance only the internals were changed?