Define the breaking change policy

[mnonnenmacher]

Once the project reaches version 1.0.0 we must have defined:

• What exactly do we consider a breaking change?
• How do we handle major releases of ORT which happen mostly due to breaking changes that do not affect ORT (Server) users.
• A deprecation policy to avoid having major releases too often.

[Etsija]

One thing that could be marked as a breaking change(or, something similar) is any change done to the API, because we decided a while ago not to include any OpenAPI related files (like ui/build/openapi.json and the corresponding UI query client in ui/src/api) into Git, so changing an endpoint leads in the UI to a direct need for

./gradlew :core:generateOpenApiSpec
pnpm generate:api

I've actually run into this several times now, so I think we need a clear and defined way of communicating these changes, and I don't know if it's a "breaking change", or something similar.

[mnonnenmacher]

One thing that could be marked as a breaking change(or, something similar) is any change done to the API, because we decided a while ago not to include any OpenAPI related files (like ui/build/openapi.json and the corresponding UI query client in ui/src/api) into Git, so changing an endpoint leads in the UI to a direct need for

./gradlew :core:generateOpenApiSpec
pnpm generate:api

I've actually run into this several times now, so I think we need a clear and defined way of communicating these changes, and I don't know if it's a "breaking change", or something similar.

I would not consider this a breaking change because if any API change breaks the UI build it would fail the CI checks and the UI fixes would have to be done in the same commit. So while it can be annoying for a developer to have to run these commands occasionally it is not affecting the users.