Adopt a versioning scheme and release cycle.

Just a thought: now there's a proper versioning scheme and we've had our first proper release, is it time to remove the alpha symbol from the top left of the menu bar? Not sure whether this is all pods or just jd.com.

I realise it's still early days, and it's useful when people are moaning about not everything working perfectly to say that it's still alpha software and not a full production release, but thought I'd mention it for those of you involved in development to decide on.

Yeah, I'd definitely say so. Nice catch, Goob!

Done. https://github.com/diaspora/diaspora/commit/4b372cfca99700d3ba95f0c91cc6bd92783de3f4

Good man. Visible progress!

It might be handy in the long run to display a version number on pods, just for the sake of making bug reporting easier.

The whole right panel thing needs cleanup and imho redesign - maybe the version number could be there as the last item - would be cool to show it for sure.

I think there is some misunderstanding on what is a major, minor and patch.

AFAIK in SemVer this is, for X.Y.Z:
X = major
Y = minor
Z = patch

This is pretty much universal in the software world. Do we agree to follow this standard? Currently Diaspora* is running the first patch and personally I would like minor changes to increment a minor version, not just a patch.

So you didn't actually read the proposal you voted on?

get over it, nobody read it :P

"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 :P

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 ?

Here https://github.com/diaspora/diaspora/blob/develop/Changelog.md