Diaspora* software release

Development
1

This thread is aimed to discuss about the next release of the diaspora* software. It will allow to decide what should be included and what is currently blocking the release. See the next-major milestone on github.

Note: This discussion was imported from Loomio. Click here to view the original discussion.

2

About the current next-major release, 0.5.0.0:

  • This is the biggest release the community ever made, so we will probably release a Release Candidate first.
  • The release is blocked by different issues for a long time. In the same time, new code is merged and introduces other regressions. We need to stop merging new features and only allow bug fixes to current release blocking issue.
  • The last big issue to solve is the chat integration which encounters several problems, including UI freezes and no idea if it scales correctly. We have no idea how long it would take to solve these issues, so, do we want to release 0.5 without the chat? Technically, we will not need to revert the chat code, simply do not expose the chat setting in diaspora.yml is enough to tell to people that the feature is not officially supported.
3

I personally think that the changelog is way too big and that we should release asap. So I would be in favor of not exposing the chat setting at the moment, and try to come back to our nearly every 3 months unofficial release cycle.

@zauberstuhl youā€™re the one who best knows the status of the chat development, what do you think?

The other core members? @jasonrobinson @dennisschubert @florianstaudacher @jhass @deadsuperhero @steffenvanbergerem @fabianrbz

4

Based on this:

The last big issue to solve is the chat integration which encounters several problems, including UI freezes and no idea if it scales correctly. We have no idea how long it would take to solve these issues

Iā€™d agree with your recommendation of not exposing the chat functions just yet.

5

I say we cut an RC asap, even today - sooner the better and then only merge in the most critical fixes and tweaks. Test that RC for at least 2-3 weeks on opt-in pods who want to try it and then release.

IMHO we shouldnā€™t disable the chat feature, instead we should label it as HIGHLY alpha and warn podmins that they activate it at their own risk and recommend waiting for the next iteration in 2-3 months once @zauberstuhl and the crew stabilize it.

Not releasing 0.5 is starting to hurt diaspora* - the majority of pods are seeing development as stagnated.

6

Agree with Jason. I think the chat need broader audience and tests.

Plus, the release is blocked by bugs that nobody resolve. These should be treated at first.

7

Maybe do a 0.4.9.9 release without a chat and then 0.5.0.0 with chat?

8

Itā€™s not a question of numbering and itā€™s not possible a the project follows the SemVer versionning numbering system, where the number of the release is determined by what work has been done :wink:

9

Ok, what now? Next steps??

10

Maybe do a 0.4.9.9 release without a chat

Nah. Either a 0.5.0.0 with or without a chat. A 0.4.9.9 would be invalid.

My vote is on releasing with opt-inā€™able chats and a fat warning it is very, very alpha.

11

My vote is on releasing with opt-inā€™able chats and a fat warning it is very, very alpha.

Agree. 0.5 canā€™t wait longer.

12

Agree, 0.5 out with warnings about alpha chat.

There are 9 issues in the milestone at the moment. Iā€™d say lets cut an RC out from current develop and then only merge into the 0.5 RC fixes - no more features that introduce potential regression and delay 0.5.

@jhass @florianstaudacher @zauberstahl @steffenvanbergerem ? Iā€™ll volunteer to do the cutting and promoting the RC to podmins.

13

Dennis:

Nah. Either a 0.5.0.0 with or without a chat. A 0.4.9.9 would be invalid.

My vote is on releasing with opt-inā€™able chats and a fat warning it is very, very alpha.

Jason:

Iā€™d say lets cut an RC out from current develop and then only merge into the 0.5 RC fixes - no more features that introduce potential regression and delay 0.5.

This sounds like a good plan to me.

14

So we should start writing the RC announcement. It will be posted by diaspora HQ, on diasporaforum.org and on the google groups. Iā€™m not too sure about the blog.

The pad we usually use to prepare release annoucement is http://pad.spored.de/p/release_notes but thereā€™s actually a 502.

15

I think itā€™s best to put only actual release announcements on the blog, rather than RC posts. We could do an interim ā€˜the next version of Diaspora is coming soonā€™ post for the blog, though, just to keep blog activity going and perhaps generate interest.

16

Yeah, the blog is probably not a good idea for RC.

If no one objects, I could create the release branch maybe tomorrow or in coming days Jonne had no objections on IRC.

17

looks good to me, maybe a last check on open PR to see if something can be merged? I would like to solve https://github.com/diaspora/diaspora/pull/5743 first for example.

18

And Iā€™d like to solve https://github.com/diaspora/diaspora/pull/5480 too.

19

Thanks, Jason. This is exciting!

20

I agree that we should have a code freeze asap and fix / merge the 7 remaining issues / PRs in https://github.com/diaspora/diaspora/milestones/next-major.