No, I can assure you we definitely do not think it's "pre-release" quality. I work closely with Brian Behlendorf, and I'm sure he would not have made the stable release if he thought it wasn't ready for prime time.
It's a little disheartening to see people pay so much attention to a fictitious number, which really has no regard to the actual state of the code/project. Whether v1.0 or v0.1 was used, the quality of the release would not differ any.
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 a little disheartening to see people pay so much attention to a fictitious number
So, rather than adapt to people everywhere and call it v1.0, let's be a little sad that calling it 0.6.1 doesn't have the same effect, and then leave it the way that it is, and complain about how irrational people are?
Or...
I know, let's make a new release of v0.6.1 called...wait for it...v1.0. And then we can move on to real issues, not fake controversy.
It's a little disheartening to see people pay so much attention to a fictitious number, which really has no regard to the actual state of the code/project. Whether v1.0 or v0.1 was used, the quality of the release would not differ any.