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!
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.
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.
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 )
I’ll work full-time on diaspora next month (June), so I’m sure that I complete the rewrite in the next month.
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 )
If you need any help in testing, feel free to ask me.
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!
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)
I don’t know what you mean with “The “able to generate a report” part of the migration feature”? The importation part of the migration-feature I want to have in the 0.7.0.0 release is, that it should be able to understand a account_migration message. So when other pods in the future start sending these messages, 0.7.x pods understand it and migrate posts and contacts of the old person to the new person. Having the new export-format ready would be nice to have, but not a blocker.
Another thing to be discussed for 0.7.0.0 would be 7259 (supported ruby versions), but since sidekiq 5.0 needs 2.2.2+ and support for 2.1 has ended, we should probably just go with 2.3 and 2.4 there (so drop 2.1 and add 2.4, as already done in the PR).
I’d like to have 6726 and 6750 to be merged before 0.7.0.0. The first one is almost finished. The second one should be rewritten and I already started the process locally and not yet published the changes (since they’ll be based on some changes from 6726).
Sure, this part too. I was indeed talking about the new export-format to be included. Let’s take a pod which stops being updated. Before that feature is included, there is nothing the user can do. Once this is there, even if the pod is not able to import a user, at least users can leave it. That’s the important point, we want users to be able to leave an outdated pod. Maybe it’s not a strong blocker, but it would be very nice to have it.
If this would be a blocker, then 0.7.0.0 will never be released. So yes, this would be nice to have, but there are many other things that are nice to have, and we can’t just put everything in this release, because we don’t have the resources to implement it. So if anybody is going to do a PR about it before 0.7, it will be included, but it’s not a blocker …
So the only things for me that are really blocking 0.7 are federation (7436) and migration (6726 and 6750), and the supported ruby versions need to be discussed.
Everything else is nice to have for me. So publisher for example, would be really nice, but I don’t see much activity there and I don’t want to wait another two month if everything else is finished (so it isn’t a blocker for me). But if it’s done before the release (or if it’s in active development and nearly finished, I’d wait), then it will be in 0.7. But if it takes as long as it takes to finish the mobile admin panel, then I don’t want to wait for it.
Federation and migration is currently in active development (migration not so much currently, but it kind of depends on the federation PR, so it’s difficult to do both at the same time). I added senyas PRs to the milestone.
For me, ‘blockers’ to a release should only be code which is needed to fully integrate already merged code or something that is, for example, going to make a major improvement in performance across the app. Individual features, no matter how useful it would be to have them in the code base (e.g. anti-spam tools) shouldn’t hold up a release unduly unless they have become critical, for example if Diaspora was being swamped by spam.
Please don’t make this a “wishlist” discussion again. We had those for 0.5.0.0 and 0.6.0.0, and I’d rather not have the same thing again.
My point of view is simple: whenever we have collected enough breaking changes to that backporting to stable gets painful, it’s time for a major release. Taking the time to create a list of things we’d like to have done in a certain timeframe never worked out for us in the past, so I highly doubt it will work out this time.
I was thinking about your script and the delete info sent to other pods. This looks like a small work but would already greatly improve the situation, instead of seeing every podmin deleting the posts one by one.
That is exactly what I was trying to ask here, sorry if it looks like a wishlist I guess it’s still because of my english skills.
So, to say it differently, what in your opinion should be in 0.7 to reach this state?
So, for those following this topic, we had to discuss this privately mainly because of the live stream surprise. The discussion is now public and available at Let's talk 0.7.0.0
)
