Can you elaborate? They seemed pretty responsive to me every time I asked for assistance in the channel... (we'd implemented something in 0.4). If "incomplete documentation" is "unserious" that would be the large majority of open source libraries. Actually blocking on completing it sounds like they were taking the release seriously to me. And I understand it taking a while. No one likes writing documentation.
I’m viewing it from the perspective of being a user who is blocked by a feature or bug fix that has been implemented for 2 years and not released. How do you trust the feature/bug fix cadence moving forward?
It’s not like users can’t run release candidates in prod, but there are many reasons not to, and good policy guides against this.
I used to be an ardent supporter of Uber’s h3 geospatial library. But we’re running into almost exactly the same issue. Bug impacting us we’re fixed in 4.0 and it’s been stuck in release candidate status for over 2 years. That’s not tenable as a user who is trying to get things done. So now we’re migrating off it entirely.
Well. In this case it's almost a labeling thing. You could make an exception for this (maintained) release candidate if in your judgement incomplete documentation (basically rust doc stubs for a significant percentage of the libraries) was (not) a blocker.
In some places we were told to never use libraries that weren't 1.0 - obviously that would be bonkers in the rust world. In these things you really have to use your own judgement...
I don't feel like their decision to make documentation a release blocker shows disrespect for the users. They were repeatedly clear that it was safe to use and feature complete.
They did note the shift from a single man project to a foundation governance took longer than expected and was part of the release as well, but, you know, non-code stuff like that also takes longer.
