Adopt a versioning scheme and release cycle.

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.