Matt's Dev Log

After several months of work, we released #WriteFreely v0.11 today / last night. This included one last bugfix I found while testing, #205 / Fix URLs in CSV exports.

The team caught some issues with templates with during our review process before merging, but then introduced new bugs with the attempted fix that weren't caught during further review. The new bug only affected instances configured for single users (not multiple users), but if a blog had any pinned posts, all blog rendering would fail and display our silly “500” error text instead of the author's writing. In other words, this wasn't an edge case, but the software catastrophically failing for a decent subset of users.

Admittedly, this is a configuration we don't currently test super-thoroughly — but nonetheless it got merged with the rest of the intended fix.

I quietly released v0.11 around 3am Japan Standard Time, and within two hours a user upgraded their instance and encountered our newly introduced bug, filing an issue for it (#207).

The bug was easily fixed when I woke up (#209), but this incident — a large release after several months, completely botched for a subset of users — made it clear we need to change how we do things in the future.

Going forward, we'll put out a Release Candidate or two before all major or minor releases. The goal will be to get more eyes on the code we're about to send out, so that we might catch silly errors like this before putting our stamp of approval on a new release.

In the meantime, skip v0.11 and enjoy WriteFreely v0.11.1! This time, you won't regret the upgrade!

Testing out ActivityPub mentions, which should work with Mastodon now.

@matt@writing.exchange, does it?

Edit: it does! And it means any fediverse replies to this post will notify me on my Mastodon account, where we can continue the conversation.

#mentions

Just seeing if this works: @darius@friend.camp

#mentions

We're working on supporting #ActivityPub mentions in #WriteFreely now (T627). The work is in progress, and last post didn't work.

Testing to see if @matt@pleroma.site gets this.

Let's see.

Testing #ActivityPub #mentions in #WriteFreely now (T627). Apparently Mastodon doesn't honor mentions in Articles (they only work with Notes — we've opened #12129 to fix this), so @matt@writing.exchange won't work. But Pleroma does honor them, so @matt@pleroma.site should work just fine.

Let's see.

This is to test Pherephone, the latest ActivityPub project from Write.as.

Testing out wf-cli

This is the command-line interface, now working with all WriteFreely instances.

I'm thinking we should bring our various command-line importers (e.g. the text importer and wf-migrate tool) into the main CLI. This fits in line with the file-syncing features we're going to eventually add to the CLI, and enables us to take advantage of certain shared, required features like account authentication. We could even leverage the existing CLI UI for things like choosing which collection to import posts to.

Many of the changes I make are small, quick fixes in response to users — some recent cases are #137 Prevent transliterated slugs exceeding length limit and #138 Don't consider post unpublished when title exists.

They're often quick fixes, taking no more than 10 minutes to fix. I usually deploy them on Write.as once they're done and I've verified the fix. I know the software well enough to feel confident deploying new code so quickly, but of course, there are always blind spots.

So I'm going to start making these small changes with pull requests, instead of committing directly to develop. This puts them on the same field as everyone else, and gives everyone visibility into what's going into the codebase (remember, you can watch the GitHub repo to get these notifications, or follow @writeas_dev@abunchtell.com in the fediverse).

This is the main reason I'd like to do it this way — to notify everyone and provide a comment period, rather than a formal code review like we do with larger features.

I'm going to leave these pull requests open for a week, and then merge if no one brings up any issues. If it turns out that the change caused some kind of regression, etc., we can fix it and reference the original pull request.

  • Update documentation
    • Tag release in documentation repo
  • Deploy changes to the Getting Started guide on WriteFreely.org
  • Tag release in writefreely repo
  • Run make release in the writefreely repo
  • Finish writing changelog in pad
  • Compile the GitHub release
    • Paste the changelog into GitHub
    • Upload the binaries
    • Publish release
  • Paste the changelog into Write.as
    • Add links to issues
    • Write extra introduction
    • Link to GitHub release
    • Publish blog post
  • Deploy Write.as for Teams application
  • Upgrade WriteFreely.host instances
  • Boost blog post on Mastodon