Hopes of a stable API

[jordy25519]

Some rough data showing the # of B1-breaksapi labelled PRs that have been merged over the last year.

I'm aware that not all the changes are equal in complexity but this at least shows some indication of how changes are being approached in the framework.

As a downstream project it feels like most our time is spent playing catch up with the changes,
there are some things where I see good opportunities to contribute PRs here but the driver feels more like "If I push my code upstream then it won't break when the next big refactor happens" vs. "this would be a valuable contribution to the ecosystem"

So this is a request to consider the complexity that's being handed to all downstream projects from the frequent refactors and changes and ultimately the detriment to contribution it has.

[HCastano]

Hey Jordan, we understand that is downstream developers it can be quite frustrating to keep up with all the changes. However, we are in the process of stabilizing a lot of the APIs and this can be seen with the 2.0.0-alpha.x releases that have been happening over the last few weeks (e.g paritytech/substrate#5340). I'm not sure what the timeline is for getting out of alpha (@gnunicorn will definitely have a better idea than me), but hang in there Jordan - it's coming :)

[gnunicorn]

Hello @Holygits ,

indeed this project is in fast development, and it will stay that way for a few parts on-going. The statistic is a bit misleading though as it tracks any breaking change on any of the crates, the majority of them are internal though and 95% users will never see/notice those changes.

However, exactly as @HCastano is saying, the key idea behind releasing 2.0 to crates.io is to make that process less burden for downstream users by adhering to SemVer and providing a Changelog that helps upgrading.

We are on the road to adding last features and than stabilising towards releasing 2.0 . We believe that is then going to be a good base for the vast majority of projects.