What's new in Pleroma: 1.1 RC1, 1.0.x deprecation, OStatus removal
We just cut the
v1.0.90 (aka Pleroma 1.1 RC1) this afternoon, so I figured it would be a good time to write a blog updating people on what is happening.
Everything about Pleroma 1.1
So the first Pleroma 1.1 release candidate has been cut, but what does that ultimately mean? When will the final release happen? Ultimately, that depends on you.
We want people to test the 1.1 release candidate and report back to us about how it performs — thus the first release candidate really begins a cycle of incorporating feedback and bug reports then cutting further release candidates.
However, don't despair! We have been using an improved release engineering process, which has left the tree in a pretty reliable state verses the 1.0 release cycle, which was somewhat seat of the pants. Accordingly, we only expect to have a single revision cycle.
This means that the expected timeline is as such:
- October 7: Pleroma
v1.0.95tag (aka Pleroma 1.1 RC2).
- October 14: Pleroma
v1.1.0tag; 1.1 becomes the new
release/1.1branch created for future updates.
- October 28: Pleroma
v1.1.1tag; revision update for anything that got caught after the 1.1.0 release.
So the key date is October 14th, that is when we expect that 1.1.0 will drop.
Pleroma 1.0.x deprecation timeline
At the moment, Pleroma 1.0.x is actively maintained. As users migrate to the new 1.1.0 release, we expect for interest in the 1.0.x branch to wane. However, we want to ensure that the transition from 1.0.x to 1.1.x goes smoothly.
As such, I plan to keep the Pleroma 1.0.x tree under maintenance (since I'm doing most of the maintenance work on it) until April 2020. This gives roughly 6 months for users to migrate from 1.0.x to 1.1.x. However, new features will not be backported to 1.0.x at this point — only security fixes. If you want new features, then you should switch to the new stable tree or follow the maint tree.
Release engineering in a nutshell
Starting with Pleroma 1.1, we have adopted a new release engineering process that is similar to how other large scale git projects do release engineering.
In this workflow, we have three branches:
stable: this branch represents the latest and greatest stable release, and is actually just an alias to whatever that release's branch is.
maint: this branch is where new changes are held until we cut a new stable release
develop: this branch contains the bleeding edge code (but we try to keep it reasonably stable)
In general, things graduate from develop to maint to stable. Every so often, we freeze
develop for a while and then cut a new maint branch, which will become the next release series.
By doing this, we allow for features to mature before exposing wider audiences to them. This ensures that people remain confident in Pleroma.
OStatus deprecation and removal
As has been discussed before, OStatus is deprecated in Pleroma since 1.0. Mastodon is removing OStatus in the 3.0 release. In general, it is time for the fediverse to move on from OStatus for a multitude of reasons. But the question remains: what is the actual deprecation plan for OStatus in Pleroma?
Right now, the plan is to disable the OStatus modules by default in Pleroma 1.2, which should release toward the end of March 2020 if we are able to keep our current cadence. After the 1.2 release, we will most likely remove them entirely, which means that OStatus will most likely be excised from the Pleroma tree by October 2020.
This timeline should not be a problem, since GNU Social intend to make a release this month with ActivityPub support, and everyone else has migrated to ActivityPub months ago.
I wanted to write a little about our OCAP plans, but ultimately I want to wait a little while before writing about this. So I will cover it in the next blog post about Pleroma instead.