We can't easily know the state of the code, but we can easily read the number that you have assigned it. That number should reflect your own assessment of the code's stability.
It's also a matter of how much cognitive load you want to impose on your users. We use dozens of different open-source packeages, each with its own version number. Can you really expect us to keep track of all of them? "Which Linux ZFS release was the first stable one?" "Uh, I think it was 0.6 something, or maybe 0.5.1?"
> We can't easily know the state of the code, but we can easily read the number that you have assigned it.
Exactly. To those who have been using 0.6.0_rc*, version 0.6.1 conveys the meaning "go ahead and upgrade, here's the stable release with no backward compatibility issue".
You will get your version 1.0 after several pre-1.0 RC releases. That's the proper release management.
It's also a matter of how much cognitive load you want to impose on your users. We use dozens of different open-source packeages, each with its own version number. Can you really expect us to keep track of all of them? "Which Linux ZFS release was the first stable one?" "Uh, I think it was 0.6 something, or maybe 0.5.1?"
Don't do that to your users. Call it 1.0.0.