Adopt a versioning scheme and release cycle.

Definitely. I think between getting a stable/unstable branch and adopting a release cycle, we could also make packaging for distorts much easier.

They all just kind of seem to fit together, and a short release cycle can help us better define short-term goals for the platform.

I'm not sure if we really should implement time restrictions, just use regular http://semver.org/ and bump version numbers if needed.

@Jonne: Thanks for the SemVer link, that's extremely interesting. I think for the sake of packaging and creating dependencies, semantic versioning is a good idea.

My thought on time restrictions: I think part of the problem is that because we haven't had any sort of time restriction at all, it's resulted in a wide-overreaching, somewhat vague roadmap, and the constant status of being "Alpha". I think that by adopting, say, a six-month release cycle (or whatever increments necessary), we could make short-term roadmaps for features, fixes, and improvements, planning accordingly for the chunk of time we give ourselves to hit release. If we have six months to get to a release, then we plan features that can be accomplished and made release-worthy within that span of time.

Granted, roadmap items would probably be smaller, but they'd also be things that we could realistically get done for a given amount of time. Furthermore, if you look at a lot of user-oriented FOSS projects (Gnome, KDE, Unity, Firefox, LibreOffice), many of these types of projects have a time-based release cycle. I believe having that encourages developers to get more done together, and can aid the collaborative process.

Partially related, we could also tag stable releases in our GitHub repo when we approach release time, pointing out to podmins, developers, and enthusiasts that the release is considered stable, or at the very least, having a green build and being stable enough to run a production environment.

We can't compare to the big FOSS projects. Yet. For Diaspora I still see the possibility that no feature/change justifying a major or minor release is done in that time. On the other hand it might be done shortly after the timed release and then we can't easily do API breaking changes because podmins might want to deploy this new feature and others want to wait for the next release.

That said I still vote for just doing SemVer, defining our "API" to not only being a potential client API and our federation protocol but also our frontend. Massive changes there should justify at least a new minor release too.

I created a new proposal since only two people (had time to) vote on the old one.

I'd really like to see some sort of time-related release cycles. we don't have to enforce it strictly (if something justifies a release, we should just go with it) and it doesn't have to be all that precise (e.g a base-cycle of 6-8 weeks, with a buffer of +-2 weeks or whatever would be enough).
But I don't really like the 'no deadlines' structure ... it's hard for me to get work done without a goal ;)

Can't "Oh yeah, if I finish that I can release a new version!" be a goal? :P

;)
I don't know about you, but as a student most of my motivation comes from approaching deadlines.

Okay I can see the motivational aspect but that's the only benefit I see, the downsides don't out weight that IMO: We would need to decide what to include, estimate if it can be done that time frame (impossible in a project where everybody can join and leave anytime) and lots and lots of bad karma for missing to include stuff while having it announced/stated or postponing a release yet again and again. Remember podmins certainly will plan downtimes for announced releases, that really gives bad karma if we miss it :)

Ok I see your point, and I think the downsides outweigh my personal motivation issue :P

RELEASE(or whatever we could call it).MAJOR.MINOR.PATCH actually according to my proposal.

I think we should just try it with Githubs milestone feature instead of a roadmap.

Seems simple enough; to be fair we haven't really used it all that much before, but seeing as it's already there anyway... ;)

Oh, just one thing I forgot in the proposal, but I think we all agree about: A changelog should be included into the repository.

Yep, that's why I did another proposal just now, so we can init the branching model and release a 0.0.1.0 the first time we got something stable in the develop branch.

SemVer scheme +1 of course.
Timing: What about a time raster. IF there is a new release, release it at beginning of the month. (quarterly is to much I guess).
You have the idea of the two advantages - dependecies + admins ? I could elaborate.

just btw for the ruby gems releases this would be very useful (as guideline!)

Hm, pushing non hotfix releases on something like every second sunday could be an option to thing about. I've to think about it a bit more.

Yay! We have a versioning scheme :)

And https://github.com/diaspora/diaspora/pull/3589 gonna already shout it out via a custom header :P

Excellent. Should we consider a v 0.1 stable release soon, or should we clearly detail out some milestones we should hit to get there? (Anything to get away from the Alpha/Beta scheme)

Nobody actually read that proposal :P
First version would be 0.0.1.0 (release.major.minor.bugfix). And I'm aiming for the first release pretty soon once my new configuration system has proven stable enough. From that on I've my personal list of things to do but I won't assign that milestones, one of the benefits of SemVer is IMO that not you tell what a new version is but the changes you make. So lets just see what happens, releasing new versions as needed ;)

My bad, sorry Jonne. What I meant specifically was that I was wondering what we need to do still so that we can start officially making stable releases. IMO, it'd be useful for anyone trying to package Diaspora for different distributions.

Have just seen the announcement on the mailing list of the first 'new' release. It all looks fantastic, and gives me real hope for the future. Thank you so much, Jonne, and everyone else involved in this initiative.

I guess the release cycle stuff is kind of open still. How we decide when to release, etc. I'm kind of thinking a monthly release cycle would be cool - just push out whatever is ready (by using a release branch of course) and bump the semver according to what kind of changes are included.

How do others feel about the releases? Personally I would like to see releases quite often, maybe monthly would be nice - not too fast but not too slow?

I think we're just doing SemVer-driven versioning and releases for the forseeable future, in which the version is bumped by the amount of actual changes and the relative scope of how much code is being changed. It's not so much that it's time-driven, so much that the code moves along and is updated automatically.

The real question is, at what level do we consider our code stable enough for release? What criteria would we need to ensure that the release build is green, that sweeping changes are documented? Finally, what strategies can we better adopt for getting the word out on releases?

I think we (or rather, the devs) will have to play it by ear a bit to start with, until there is a good pool of devs and work is rolling. A fixed release cycle with frequent updates might put too much pressure on the few core devs we have at the moment. (I think it's only a few still, in any case.)

So I think for the time being, it would be better to have a release when there is something ready to be released and worth of a release update, rather than on an fixed time scale. The main thing is 1) to keep things moving, so that we don't again hit a patch in which nothing is (apparently) happening with D* development, and 2) not to promise anything which then isn't delivered. As long as things are happening, even if there is no new release for a while because the devs are hard at work on a major structural change which is taking a long time (for example), there doesn't need to be a release every few weeks, in my opinion. This is where Sean and others can help things along with regular and open communication about what is happening behind the scenes. I say open, because for a time the communication we did get with the core team was opaque, and that compounded the problems the D* community was experiencing.

All this is said as a non-dev, so might be completely wrong. I guess it is for Jonne and the other core devs to decide amongst themselves what is the best release scheme.

The questions in Sean's second paragraph are worth asking, and one reason I'd be wary of a fixed-time release cycle would be the possibility of rushing something out before it has been fully tested, in order to meet the deadline. If communication about progress is frequent and open, I don't think new code needs to be released so frequently.

(I assume preparing a release and release notes also takes dev time, so it might be good to wait until there is a significant change in the code before releasing for this reason as well.)

Apologies if any of this is off-beam; as I say, unfortunately I know next to nothing about coding and so can't help with this.

Blimey that was a long post. Sorry. Without being able to preview, and because the input box remains small so text disappears upwards, I seem to end up writing far more than I realised, and then not being able to edit it down.

since we successfully adopted the versioning scheme (whis is what the headline says), I'd say everything else could go into a new discussion? or how do we wanna handle it? (just hijack the thread or start a new one?)

The topic is " Adopt a versioning scheme and release cycle" so seems right to me? :) A discussion is different from a proposal, there is no reason we cannot discuss here and have more proposals relating to the subject. Adding extra discussions will just fragment the discussion imho.

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