Yay! We have a versioning scheme 
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 
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!
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?