get over it, nobody read it 
âThe version is prefixed with another number which will be increased at community decision instead of a major release. This is to avoid a false sense of rapid development and increasing stability while still maintaining a meaning in the version number changes from the start.â
Ah must admit I didnât read it. OK so I agreed. Proposals are only valid until another proposal is accepted (if we want to be rude we canâŚ).
Anyway, if we donât want to be rude, just saying now that I donât think this is a good idea after all. It doesnât follow good practices that have been found to work well in the software world. Take anyone from the internet who knows semver and give them our version number and they will think we havenât even reached the first minor version yet. It just doesnât look good IMHO.
Did someone actually read that paragraph of the proposal and agrees to it? Then it is fine to me - I just assume there was a big misunderstanding here and that we should follow major.minor.patch as most of the projects on in the world (pure semver or not).
Jason, you are welcome to write a proposal if you think something needs to be improved. Weâre a FOSS project, not The United States Congress. Change for the sake of improvement is the very nature of good development.
I just want to clear what I thought was a misunderstanding 
I donât have a big fuss with the deal now that I know it was actually in the proposal. Still, I donât look forward to telling everyone who I talk about Diaspora* to that âno the version number is so small because we decided, not because it implies the state of the softwareâ, done a few of those alreadyâŚ
I wonât fuss with a proposal to change if no one else agrees with my view. And if no one agrees, I will promise not to talk about it any more
Perhaps the first figure could be substituted for a letter to signify community decision rather than a major release. So we would now be on A1.1.2 (I think). Either that or just drop that variable from the version numbers. Or leave it as it is.
I donât disagree with you, Jason, and others may feel the same way. My point is, youâre not going to know the true value of some ideas without discussing/proposing it. You may find yourself pleasantly surprised. You canât objectively know whether an idea will be supported or not without giving it a good shot. And if things stay the same, thatâs okay, too.
Consensus isnât about steering a project by majority rule; itâs about figuring out good compromises that everyone can more or less say âIâm okay with this, itâs been on my mind too, letâs do it and see how it works out.â
The point of prefixing is perception. With the first major feature added we need to bump the major release and would reach 1.0. And more people will think âOh, itâs stable nowâ then âOh, they added a major feature because theyâre following SemVerâ. Itâs just to prevent false sense of progress and stability where thereâs none.
Well, actually:
"Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes."
So Iâd say 1.0 would very much be up to us to define - software doesnât just jump there without it being declared stable 
But letâs keep things as they are. If someone else raises the same concerns as I do at some point we can discuss more
My 2 cents : i donât want to see a 1 in the major version number until there still is bugs known but not fixed
By the way, we need a place to post changelog of every version, and maybe not only in the wiki (or, at least, make a direct link from Diaspora to this page). This page already exists somewhere ? Where is the current draft of the v0.0.2.0 changelog ?