Loomio

diaspora* software release

F Flaburgan Public Seen by 58

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.

F

Flaburgan Thu 19 Mar 2015 6:26PM

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.
F

Flaburgan Thu 19 Mar 2015 6:34PM

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

DU

[deactivated account] Thu 19 Mar 2015 8:43PM

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.

JR

Jason Robinson Fri 20 Mar 2015 6:40AM

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.

DU

[deactivated account] Fri 20 Mar 2015 8:38AM

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.

M

Maciek Łoziński Fri 20 Mar 2015 1:42PM

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

DU

[deactivated account] Fri 20 Mar 2015 1:52PM

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 ;)

DU

[deactivated account] Sun 22 Mar 2015 9:36PM

Ok, what now? Next steps??

DS

Dennis Schubert Mon 23 Mar 2015 5:46PM

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.

DU

[deactivated account] Mon 23 Mar 2015 7:58PM

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.

JR

Jason Robinson Mon 23 Mar 2015 8:06PM

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.

G

goob Mon 23 Mar 2015 11:14PM

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.

F

Flaburgan Tue 24 Mar 2015 4:07PM

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.

G

goob Tue 24 Mar 2015 6:35PM

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.

JR

Jason Robinson Tue 24 Mar 2015 8:22PM

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.

F

Flaburgan Tue 24 Mar 2015 9:40PM

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.

DU

[deactivated account] Tue 24 Mar 2015 10:58PM

G

goob Wed 25 Mar 2015 2:54PM

Thanks, Jason. This is exciting!

SVB

Steffen van Bergerem Thu 26 Mar 2015 2:35PM

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.

DU

[deactivated account] Thu 26 Mar 2015 8:49PM

Is anyone able to provide a likely ETA for those remaining issues?

JR

Jason Robinson Sun 29 Mar 2015 7:07PM

Sorry I had a more busy weekend than I had planned so didn't get to do the RC branch yet. I will do it and promote it tomorrow evening if all goes well.

JR

Jason Robinson Mon 30 Mar 2015 2:55PM

OK now there is a release/0.5.0.0-RC branch available. I'll compile a message a bit later and send out, for pods to test. Need to add some warning text to the changelog as well.

For adding fixes to the RC - I'd suggest we don't merge anything to the RC branch unless it concerns the last remaining 3 issues or some other regression in 0.5. Anything else, it would be nice to get a few core devs agreement before cherry-picking commits to the release. I'll happily do that on request.

This also means merging for next-next is open, if something is waiting for that :)

F

Flaburgan Mon 30 Mar 2015 3:03PM

Awesome, thank you Jason :)

JR

Jason Robinson Mon 30 Mar 2015 7:05PM

Draft post on the pad: http://pad.spored.de/p/release_notes

OK to promote? Any additions, missing stuff, etc?

F

Flaburgan Tue 31 Mar 2015 9:32AM

@goob any chance you can review the announcement before we post it?

Has anyone else anything to say?

G

goob Tue 31 Mar 2015 11:26AM

I'll have a look now.

F

Flaburgan Tue 31 Mar 2015 11:30AM

Awesome. As soon as it is ready, I think I'll post it first on diasporaforum.org (someone wants to do it on Google Group please?). Maybe some podmins will then try to upgrade an give us feedback. After that, I'll post it on diaspora HQ.

G

goob Tue 31 Mar 2015 11:52AM

Looking good! Have made a few changes. Please check I haven't introduced any errors on the technical side.

F

Flaburgan Tue 31 Mar 2015 12:55PM

F

Flaburgan Wed 1 Apr 2015 9:26AM

diaspora-fr.org and diasp.net switched to 0.5. Those were pods running the dev branch so we didn't learn from these upgrades.

https://diasp.ca/ also upgraded, I don't know if this pod was running the develop branch, I will try to contact the podmin.

F

Flaburgan Wed 1 Apr 2015 2:07PM

G

goob Wed 1 Apr 2015 4:17PM

Those were pods running the dev branch so we didn’t learn from these upgrades.

Is anyone running the stable code on a production pod likely to update to a buggy release candidate? I would have thought all the testers would be those already running develop. Surely there's still useful feedback to be gained from those pods. If we can't learn from those pods, there would probably not be much point in a release candidate.

G

goob Wed 1 Apr 2015 4:20PM

If we do need production pods running stable to update, perhaps we should include that in the release announcement.

F

Flaburgan Thu 2 Apr 2015 12:01PM

Shared with diaspora HQ: https://joindiaspora.com/posts/5865715

G

goob Thu 2 Apr 2015 9:11PM

Well done.

G

goob Thu 2 Apr 2015 9:13PM

ps: one pod running 0.4.x is updating to the RC: https://pod.orkz.net/posts/1968370

JR

Jason Robinson Thu 2 Apr 2015 10:27PM

Just shouted out with the official non-d* social media accounts - just for some buzz :)

JR

Jason Robinson Sat 4 Apr 2015 7:41AM

More feedback: https://iliketoast.net/posts/569515

It seems so far the main issues are:
* DB migrations being super slow
* Upgrade instructions not being followed

JR

Jason Robinson Sat 4 Apr 2015 2:13PM

Also another: https://iliketoast.net/posts/569232

SetMysqlToUnicodeMb4: migrated (580.1959s)

That one MySQL migration is super slow.. that pod has 124 users in total. I wonder how long it will take to run the migration on some really big pod? I suppose larger pods have more powerful DB engines so can't just count pod size.. still, we should place a big warning in the announcement that database migration can take a loooong time.

F

Flaburgan Sun 5 Apr 2015 9:01PM

Does this migration have to be done when diaspora* is stopped?

F

Flaburgan Tue 7 Apr 2015 10:33AM

We got feedback on the forum, that's nice. It looks like we're now releasing too big releases to have a generic "Updating" page on the wiki. A specific guide with every steps in the right order for each release looks more appropriate. I don't know if this should be directly in the changelog or on the wiki.

G

goob Tue 7 Apr 2015 11:24AM

Hmm, the steps are given in the changelog when needed. It would seem unnecessary to repeat them in the wiki, and also make that page harder to follow, because you'd have to find the relevant instructions for the version you want to update to. And it might lead to people doing manual steps when updating to a version which doesn't require them.

How about a general note: 'When updating to a major version (0.x.0.0) you may need to perform some manual steps, for instance a database migration, before updating the app code. Please check the notes at the head of the changelog for the version you are updating to before starting to update.'

(Could prob word this better....)

F

Flaburgan Tue 7 Apr 2015 12:02PM

How about a general note: ‘When updating to a major version (0.x.0.0) you may need to perform some manual steps, for instance a database migration, before updating the app code. Please check the notes at the head of the changelog for the version you are updating to before starting to update.’

We already do that, the problem is that the different manual action are not in a specific order. You'll understand what I'm saying reading https://diasporaforum.org/t/my-0-5-0-0-rc-feedback/312

JR

Jason Robinson Wed 8 Apr 2015 7:53PM

Does this migration have to be done when diaspora* is stopped?

Well, not a DB expert, but I'm willing to bet yes.

But another question worth asking is, is this migration necessary. @dumitruursu ? @jhass ? You are the guys who worked on these. I'm assuming at least that the migration takes time doing the shorten_indexes part (https://github.com/diaspora/diaspora/blob/develop/db/migrate/20150106050733_set_mysql_to_unicode_mb4.rb#L48).

JH

Jonne Haß Wed 8 Apr 2015 7:55PM

Yes, it is necessary.

JR

Jason Robinson Wed 8 Apr 2015 7:56PM

Yes, it is necessary.

Sorry - I'll rephrase. Is the shorten_indexes part necessary? :)

JH

Jonne Haß Wed 8 Apr 2015 8:00PM

Yes, at least on MySQL it is. And I really don't want to let the schema diverge that much between MySQL and PostgreSQL pods. Besides it runs faster on PostgreSQL anyways.

DU

[deactivated account] Wed 8 Apr 2015 8:15PM

You guys have seen how long migration took on a small 1.6GB db, right?

Any feedback from ppl running >20GB dbs yet?

JR

Jason Robinson Wed 8 Apr 2015 8:25PM

And I really don’t want to let the schema diverge that much between MySQL and PostgreSQL pods.

Yes, that is a valid point. Reading into index length I'm not really just sure why we set it. It certainly doesn't seem like a required thing to have. But then, the shorten_indexes seems to do many other changes too, at least looking at the schema.rb, so I guess picking it out as an optional step would be tricky...

Would be nice to have more pods report feedback.

DU

Dumitru Ursu Thu 9 Apr 2015 8:49AM

@dennisschubert ran the migration on a ~50GB database, and it took 1 hour 31 minutes. We made some tradeoffs with @jhass, and this is the best we could do. Given the state of MySQL utf8 support, I would drop it altogether, but..meh, I know we can't do that.

One solution is to use another engine for MySQL(innoDB), but required changes with administrative privileges, and many podmins might not have that.

DS

Dennis Schubert Thu 9 Apr 2015 4:01PM

We're already using InnoDB, at least my database does. So I doubt this makes any difference.

DS

Dennis Schubert Thu 9 Apr 2015 4:22PM

I am wondering if it is actually needed to modify each column on its own? I always thought an ALTER TABLE also affects the columns in it?

Edit: Just for the record, everything is blazingly fast without the column-loop: https://gist.github.com/denschub/dd4c23c3b83b343378e8#file-without_columns

But that makes me wonder... I don't think it does a conversion at all since it is way too fast...

DU

Dumitru Ursu Sat 11 Apr 2015 7:57PM

@dennisschubert, innoDB on it's own doesn't do much. But using the large indexes option, and another trick that I forgot, you can increase the index size, which would make the whole index trimming process redundant.

DU

[deactivated account] Mon 13 Apr 2015 6:27PM

So, what are the next steps to making v0.5.0.0 a reality?

JH

Jonne Haß Mon 13 Apr 2015 9:23PM

DU

[deactivated account] Tue 14 Apr 2015 7:55PM

Sweet :+1:

DU

[deactivated account] Thu 16 Apr 2015 8:12PM

Only three left now! #exciting :)

G

goob Thu 16 Apr 2015 9:09PM

I got rid of one of them, yay!

DU

[deactivated account] Mon 20 Apr 2015 9:37AM

Nice one @goob

Now stalled on three it would seem....

G

goob Wed 22 Apr 2015 10:34AM

Great work by @steffenvanbergerem to clear the last two blockers. Thanks!

F

Flaburgan Wed 22 Apr 2015 10:44AM

Yeah, we should now be able to release soon.
I listed the most important change in the pad and started to write some articles on my blog about the release. Goob already translated the privacy one, I think it would be nice to publish it on the foundation blog once it's formal enough. @jhass @steffenvanbergerem @dennisschubert mind to review it to be sure I don't say bullshit from a technical point of view?

DU

[deactivated account] Thu 23 Apr 2015 8:33AM

https://github.com/diaspora/diaspora/milestones/0.5.0.0

Bummer, we couldn't find anything

w00t \o/

Great work everyone!!!

Now I'm really excited :))

G

goob Fri 24 Apr 2015 11:43AM

I realised last night that we're coming up to 5 years since the Kickstarter campaign, and thought it would be nice to tie in the release to that if possible.

I've just checked and the Kickstarter campaign was opened on 24 April 2010, five years ago today. It ended on 2 June, which is perhaps later than we want to wait to release 0.5. But if we can tie it in somehow, it would be good, I think, for publicity.

It would be great to get a blog post out today, but I don't really feel I have energy to do this at the moment. Anyone else? @flaburgan, @jasonrobinson?

F

Flaburgan Fri 24 Apr 2015 1:00PM

Well to be honest I really don't know how to present the diaspora Inc period of the project. @deadsuperhero was working on an history blogpost during a time. I'm not sure what we should say, the result of the beginning of the project is clearly mitigated and I don't think I'm the one who should look back and draw an overview of what happened.

G

goob Fri 24 Apr 2015 1:51PM

I don't think we have to present a potted history (although that would be interesting too). I think a simply 'It all started 5 years ago, and this is where we are now, with 0.5 coming out' - as much as anything, to jog the memories of journalists and bloggers who got excited about the project 5 years ago and have since forgotten about it.

I'll see if I can do something later, but I'm not feeling great today.

G

goob Fri 24 Apr 2015 3:05PM

Here’s a very rough first draft:

It all started 5 years ago today

Yes, it was on April 24 2010 that four kids from New York University, Maxwell Salzberg, Dan Grippi, Ilya Zhitomirsky and Raphael Sofaer, launched a campaign on the then young Kickstarter platform, asking for $10,000 to fund them for a summer project to create a decentralized social network. The campaign went viral, and 40 days later more than $200,000 had been pledged, and diaspora* was born.

Since then it's been a long road with a lot of hurdles, technical and otherwise, in realising this initial vision, but the project has remained vibrant and growing throughout that time, and the community is still working to achieve a decentralized network which gives users flexibility while guarding their privacy.

The project, now owned by its community members, is about to make another major release, version 0.5.0.0, including big features such as chat among many bug fixes and performance improvements. Keep your eyes open for this release, which will be announced very soon.

I’m not very happy with it, but if anyone wants to use it as a basis to write something worth posting, that would be great.

F

Flaburgan Fri 24 Apr 2015 3:16PM

Not sure about "Kids" :p Students I guess? And the chat is not really ready, we present it as alpha, I don't think we should promote it that much here. Apart from that, nice paper :)

DU

[deactivated account] Sun 26 Apr 2015 7:58PM

Ok, so what happens now in terms of making 0.5.0.0-FINAL a reality?

F

Flaburgan Sun 26 Apr 2015 9:07PM

@Rich for the code, to test again the migration in a mysql database now that the encoding change is done differently. This could also be tested on a postgreSQL db.

We also need to prepare the announcement, and to create a better "How to upgrade" page. The RC showed us that the instruction was too confusing.

DS

Dennis Schubert Sun 26 Apr 2015 9:17PM

This could also be tested on a postgreSQL db.

Ehm. Nope. The migration only runs on MySQL.

DU

[deactivated account] Mon 27 Apr 2015 7:56AM

test again the migration in a mysql database

Is someone doing this? If not, I can do this later in the week if it will help.

F

Flaburgan Tue 28 Apr 2015 8:41AM

@rich1 it would be nice. I should be able to do the upgrade guide on friday.

JH

Jonne Haß Tue 28 Apr 2015 9:37AM

I threw a first version up at https://wiki.diasporafoundation.org/Updating

Feel free to edit it in case I missed anything.

F

Flaburgan Tue 28 Apr 2015 10:00AM

Awesome Jonne, thanks. I just reinstalled my laptop with Ubuntu 15.04 released this week-end, so I will first install diaspora 0.4 on it, and then do the upgrade, so I'll be sure everything is done :)

DU

[deactivated account] Tue 28 Apr 2015 8:21PM

I'll test MySQL tomorrow, along with the new docs from @jhass - great stuff :)

DU

[deactivated account] Wed 29 Apr 2015 3:32PM

Ok, I've run this migration again on MySQL today and I don't know what's changed but the migration time went down from 1351s to just 271s for a 1.6GB database!

That's 22mins down to just 4mins :o

F

Flaburgan Wed 29 Apr 2015 3:36PM

Awesome! Did you try to use the DB after the migration? Everything is fine?

DU

[deactivated account] Wed 29 Apr 2015 3:57PM

I forgot the custom splash page gets trashed :( Maybe include a mention of this in the updated guide from @jhass ?

Otherwise, no issues to report, migration from 0.4.1.3 to 0.5.0.0-RC went fine!

JH

Jonne Haß Wed 29 Apr 2015 3:59PM

@rich1 uhm, the custom splash page is the first note after the steps.

DU

[deactivated account] Wed 29 Apr 2015 4:02PM

The surrounding markup for the custom splash page changed slightly, please refer to the changelog

D'OH!!!

Thanks :)

In which case, I have zero issues to report, the db migrate was sooooo fast this time! Amazing work guys :)

JR

Jason Robinson Thu 30 Apr 2015 9:13AM

Awesome, guide looks good! Shall we start talking about a release date? How about coming weekend, I'll at least be home to help with that. Sunday is generally a good day to release IMHO. Most of the off-d* promo could be then done on Monday which is a better day to spam social media.

F

Flaburgan Thu 30 Apr 2015 9:38AM

I'm available this week-end :)

G

goob Thu 30 Apr 2015 11:02AM

Monday bank holiday in UK and quite a few other countries, I think (May day). Obviously social media is 24-hour, but it might still not be quite as good as another Monday.

JR

Jason Robinson Fri 1 May 2015 10:35AM

Hmm good point. Maybe during the week? We still need the release announcement anyhow. Tuesday or Wednesday?

F

Flaburgan Fri 1 May 2015 11:42AM

We can also release this weekend, but only start promoting on external social network on Tuesday. That way if we find a regression between Saturday/Sunday and Tuesday we have time to fix it :)

G

goob Fri 1 May 2015 12:28PM

@flaburgan, hehe! I think we should trust the release candidate process, though...

Thanks for starting a draft release announcement on the pad. I have changed the formatting so it will work with Markdown (no leading spaces for paragraphs in lists, etc), linked to each PR, added a short introduction and edited the text a bit for clarity.

Please feel free to play around with it further.

DU

[deactivated account] Sun 3 May 2015 9:14AM

A Bank Holiday weekend would have been the ideal time to release because I have the day off work and could have upgraded my pods lol :)

#selfishreasonsonly

JR

Jason Robinson Sun 3 May 2015 12:28PM

It shall happen today! Unless someone strongly objects... plz feel free to work on the release announcement in the pad, linked two comments above by goob.

F

Flaburgan Sun 3 May 2015 1:07PM

Go from me :)

G

goob Sun 3 May 2015 4:01PM

Thanks chaps for fixing this all up - I had a total hard drive crash last night so it might be a few days before I'm back on my computer, looks like I don't have to worry!

DU

[deactivated account] Tue 5 May 2015 9:32AM

Thanks chaps for fixing this all up

I'll second that!! Great work everyone, I'm getting some really positive feedback about 0500 :)

JR

Jason Robinson Fri 8 May 2015 7:58PM

Some issues with 0.5 sidekiq stability: https://iliketoast.net/posts/609311

F

Flaburgan Mon 21 Mar 2016 3:07PM

Hi everyone, I bring back this thread from death to discuss about the 0.6.0.0 release.

The milestone is accessible on github. Let's do some bug triage.

I'd like to discuss what we want to include in this milestone, freeze it and do our best to release. Next major was almost a year ago, it's time to move forward :)

So, here is the issue to triage (feel free to add some):

Blockers (we cannot release if those issues are not fixed) :
- /contacts page is really slow #6107
- /tags pages are slow #6152
- Sidekiq 4 or sidekiq-cron is leaking memory #6763

Would be nice to see it included:
- Don't retry dead pods indefinately #6220
- Use @supertux88 's diaspora_federation gem v0.1.0
- New publisher with markdown editor 6651
- Polished XMPP chat
- Anything else needed about the API?

Do I miss anything (especially in the blocker bugs)?

SVB

Steffen van Bergerem Thu 24 Mar 2016 11:08PM

I don't think #6107 and #6152 should be blockers. These issues already exist on the current master branch and at least for #6107 there isn't even a vague idea how one could fix it.

F

Flaburgan Wed 30 Mar 2016 1:31PM

So if #6107 and #6152 are not blockers and with #6763 not present anymore on d-fr, the first version of the federation gem is the last blocker?

DS

Dennis Schubert Wed 30 Mar 2016 2:02PM

yeah

F

Flaburgan Tue 24 May 2016 9:23AM

Quoting @denschub from this topic

Release 0.6.0.0 has been in the pipe for a loooooong time and we really need to ship it. What should be included in the release? Should we stop after the federation rewrite? Should we do some more extensive database optimizations to maybe improve the performance? Should we try to make the chat 100% stable, pretty and fancy? Should we push the API development? How much work will get pushed into the tasks and how far could these features delay the release?

I really think we should stop postpone the release. I would even freeze the code now apart for bug fixes and release 0.6 instead of 0.5.10. We didn't do any progress on any topic listed here (chat, API...) for months, I see no reason to wait longer. It will be included in 0.7 release if ready, it's not a problem. The only active development actually is the federation gem, even if the last release is from March. It is also already included in master. So @supertux88 can you tell us if you need to block the release to finish something in the coming days, or you will need weeks anyway so we should release and we will include the rest of your work in the following minor version?

DS

Dennis Schubert Tue 24 May 2016 10:02AM

I disagree. Especially because there is work going on in the federation layer, we should finish it in this release. At the moment, federation is broken as hell and we tell people that everything will get better in the next major release. If we want to get out of the "always buggy" state, we actually need to deliver the things we promise to people. When we don't include the federation rewrite in 0.6.0.0, it would have to wait until 0.7.0.0 since the embedding probably brakes some stuff, which we'll never discover in the short one week freeze cycle in our stable release.

The chat and the API will not hit 0.6.0.0 for sure, neither will be the account migration included by any chance. But since the federation work is on a more-than-75%-done state and @supertux88 will be able to work even more in the upcoming two months (you know, I'm in near-daily contact... ;)), freezing 0.6.0.0 now would be simply wrong in my opinion.

0.7.0.0 is nothing I have on my schedule since it may not even be released this year, so why even bother about thinking about that now.

F

Flaburgan Tue 24 May 2016 10:15AM

Thank you Dennis. I agree with everything you said here, this reasoning is logical. But it's also based on "one major release per year". If we deliver more often, then it's not a problem to postpone a feature. So if @supertux88 needs at least 2 months, we could release 0.6 now and 0.7 with the new federation in September (time for code writing + tests). I agree "we actually need to deliver the things we promise to people.", but if we know for sure that federation will not be ready before September anyway, why do we block the other nice changes?

DS

Dennis Schubert Tue 24 May 2016 10:24AM

But it's also based on "one major release per year"

No, that's based on "release a major when we have something to release". A major release is something huge, that gets special attention, even a dedicated announcement post. Maybe even some media coverage if we do it right (and I guess we can agree that this would be very much needed).

If we postpone the federation to 0.7.0.0 and, let's say, we push that in fall. What do we have to show off? A new federation layer? Why should someone external even care? I doubt the chat will be polished and I doubt the API will be done in fall. So we'd have a major with... nothing interesting for external people. Not that nice.

If we bundle 0.6.0.0 with the federation, we have something to show off to external people ("look, everything looks fancy!") and magically, the federation stability improves. Win-win!

DS

Dennis Schubert Tue 24 May 2016 10:27AM

Also, we do have some regressions left to fix. Maybe, if all these are done and the federation is still not done, we can think about releasing without the federation magic. #5847 is probably an easy fix, but #6787, #6152, and #6107 look like they'll eat some time. The latter is an issue that annoys a lot of people.

I just realized that the issues I mentioned were not assigned to the 0.6.0.0 milestone, I fixed that just now.

F

Flaburgan Tue 24 May 2016 10:43AM

If we bundle 0.6.0.0 with the federation, we have something to show off to external people ("look, everything looks fancy!") and magically, the federation stability improves. Win-win!

This is definitely the best scenario, but to see it happens in 4 more months is a shame :(

But you're right, let's fix the regressions first and we'll see then the state of the federation gem.

S

SuperTux88 Tue 24 May 2016 12:01PM

The only active development actually is the federation gem, even if the last release is from March. It is also already included in master. So @supertux88 can you tell us if you need to block the release to finish something in the coming days, or you will need weeks anyway so we should release and we will include the rest of your work in the following minor version?

The gem itself is 99% complete (but I don't release it until I'm sure that I don't need any changes). I'm currently working on rewriting the whole federation-layer in diaspora (that's why you don't see much work in the gem-repo now), using the new gem. This work is 75% done (receive works already, but needs fine tuning, send is half done).

The main rewrite should definitely be done in a major release, because it needs good testing. Cleanups and smaller bugfixes for federation stuff, that is easier after the rewrite can also be done in minor releases (I'm not finished with work after the rewrite :wink: )

I'll work full-time on diaspora next month (June), so I'm sure that I complete the rewrite in the next month. :smiley:

CS

Comrade Senya Tue 24 May 2016 12:12PM

The main rewrite should definitely be done in a major release, because it needs good testing. Cleanups and smaller bugfixes for federation stuff, that is easier after the rewrite can also be done in minor releases (I'm not finished with work after the rewrite :wink: )

If you need any help in testing, feel free to ask me.

F

Flaburgan Tue 24 May 2016 12:16PM

I'll work full-time on diaspora next month (June), so I'm sure that I complete the rewrite in the next month. :smiley:

That's an awesome news!

G

goob Tue 24 May 2016 6:55PM

I think it would be good to release once we have something major ready to be released. We've already got UI changes and so on. The federation rewrite will hopefully bring major performance improvement (I haven't been following the progress closely, so I don't know what it actually will provide.) If the federation rewrite is approaching its final stages, and is likely to be ready before too long (say another couple of months), I would wait for that to be ready for release and then hit the button!

F

Flaburgan Mon 27 Jun 2016 2:49PM

So the good news of the week-end is the merge by Dennis and Jonne of the new federation gem by Benjamin. It's the most important change done by the community so far.

There are still issues to solve before the release but I feel like we can start to prepare its promotion, because there is work to do ;)

On our blog:
We could write a separate blogpost only about the new migration. I was also thinking about the OpenID connect, not sure how big we want to promote that.

In diaspora*:
We could promote 0.6 as we did for 0.1. To do that, we basically need to:
- Choose which features we want to promote
- Create an image for 0.6
- Pick an hashtag for 0.6 (#diaspora0600 for example)
- Write the posts
- Would be even better if we can translate them

In the press:
- Write a press release
- Translate it
- For each language we have a translation,
- List the press websites which could be interested
- Send them the press release

Any other idea?

F

Flaburgan Mon 27 Jun 2016 3:07PM

Hm, I'll let this thread to talk about technical details of the release (when, what, how...) and move the communication discussion in the existing one