Public API breaking changes in major version zero

[cosenal]

In recent issue discussions and community calls, concerns have been raised about potential breaking changes in the API. Let's discuss the specific cases in their respective issues (#2245, #2204, etc.)

Here we should discuss what's the mantainers consensus on braking the public API, given that Mitiq is still in a beta version (Latest release is 0.35 at the time of writing this #2255.)

As @natestemen pointed out, if we strictly adhere to Semantic Versioning 2.0.0 guidelines, then their Item 4 says

Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

If we think having Mitiq as stable is important for users, and we are confident it's in fact stable, we shall release a stable 1.y.z version. Otherwise, we shall move faster within beta without worrying about breaking changes. At the moment we are in a limbo between the two. Thoughts/opinions?

[natestemen]

My impression is that we've kind of been operating as if we have a 1.0 release. We try relatively hard not to introduce breaking changes, and we haven't removed any of the less used techniques. I think there's value in this approach since there is no clear "winner" in QEM so far.

We simultaneously need to be able to add and optimize stuff relatively quickly, but also demonstrate to people that they can rely on our tool if they want to put it into production. I wonder, how much do we signal to people that Mitiq is not ready for production by not having a 1.0 release, despite being pretty stable. I hope not too much. This is probably a good question we should be asking people about in the quantum ecosystem interviews.

I want to hear other people's opinions too. @willzeng what are your thoughts on Mitiq's value here regarding stability and introducing breaking changes?

[natestemen]

@nathanshammah do you have thoughts on stability vs breaking changes?

[willzeng]

My two cents is that we don’t need to make an abstract policy here. We can decide on a PR by PR basis and/or a milestone by milestone basis what we want to add and keep. We want to keep development flexibility in general because the space is moving so quickly.

[natestemen]

Agreed, an abstract policy would be too limiting. Mostly looking for guidance/opinions.

want to keep development flexibility in general because the space is moving so quickly.

Agreed. Generally I think we should try to keep things consistent if it's easy, but we should also be brave enough to change APIs if we see a big improvement in doing so.