takahe/docs/releases/0.10.rst

2.5 KiB

0.10

Released: Not Yet Released

This release is a polish release that is prepping us for the road to 1.0.

This release's major changes:

  • Stator, the background task system, has been significantly reworked to require smaller indexes, spend less time scheduling, and has had most of its async nature removed, as this both reduces deadlocks and improves performance in most situations (the context switching was costing more than the gains from talking to other servers asynchronously).
  • Old remote posts are now automatically pruned out of the database after a configurable horizon time, defaulting to 90 days. Posts from local users and posts that have been interacted with (liked, boosted, pinned) by local users are never deleted. You can change the deletion horizon with the TAKAHE_REMOTE_PRUNE_HORIZON setting.

Minor changes also include:

  • Followers-only mode now works correctly inbound and outbound (though outbound may need the other server to refresh the profile first).
  • Profile pages are no longer shown for remote identities; instead, users are linked or redirected directly to the remote profile page.
  • Inbound migration has been implemented, but is disabled by default as outbound migration is not yet complete, and we don't want to release a system that captures users with no outward path. If you really want to enable it, set TAKAHE_ALLOW_USER_MIGRATION=true in your environment.

If you'd like to help with code, design, or other areas, see /contributing to see how to get in touch.

You can download images from Docker Hub, or use the image name jointakahe/takahe:0.10.

Upgrade Notes

Remote Pruning

Post pruning is now in and comes enabled by default, as it is not directly destructive (it will only delete content that has not been interacted with locally and which can be re-fetched).

Nevertheless, if you want to avoid post deletion triggering on your server at all, you should set the TAKAHE_REMOTE_PRUNE_HORIZON environment variable to 0.

Migrations

There are new database migrations; they are backwards-compatible, but contain very significant index changes to all of the main tables that may cause the PostgreSQL deadlock detector to trigger if you attempt to apply them while your site is live.

We recommend:

  • Temporarily stopping all instances of the webserver and Stator
  • Applying the migration (should be less than a few minutes on most installs)
  • Restarting the instances of webserver and Stator