So far we’ve done “experimental” releases for Pidgin 3 but we never really documented what it means to be experimental or what comes after that so I’m going to attempt to tackle here.
Purple 3 and Pidgin 3 provide public APIs as well as public ABIs for other developers to consume by create plugins, additional user interfaces, as well as other things. These APIs and ABIs have compatibility guarantees that allow everything to keep working regardless of updates. This is very similar to Semantic Versioning which you may have head of.
With so much changing in Purple 3 and Pidgin 3 there’s is absolutely no way we’re going to get this correct on the first try and thus need the flexibility to be able to not provide those compatibility guarantees until we’ve proven them out to at least a basic level. If we attempted to provide some guarantee we’d be on Purple 1337 by now and have many people angry at us for constantly changing stuff.
To work around this we’ve defined five phases for Pidgin 3’s development; experimental, alpha, beta, release candidate, and general availability which define what level of API and ABI, if any, that we’re guaranteeing.
The experimental phase gives absolutely no attempt of any API or ABI guarantee. This phase has been meant to let us experiment and develop things quickly without having to worry about things like deprecation paths and migrations. This is why we’ve said “develop against Purple 3/Pidgin 3 at your own risk” because things will change drastically day to day. For example, we just rewrote the way account settings work and we started by deleting the existing stuff.
With the alpha phase, our goal is to stabilize the APIs around protocol plugins. Abstracting out every chat protocol/network under the sun as well as some non chat protocols/network is difficult and we realize that it needs some additional time to bake.
So the alpha phase says, we’re pretty confident on the protocol specific APIs and shouldn’t need to rewrite anything, but will may need to tweaks some things along the way. This also doesn’t mean that we’ll have everything defined, but enough to get full chat support working for the protocols. But notably right now we have not solved the history and logging APIs but those will be coming eventually.
Beta is similar to alpha, but instead of targeting the protocol specific APIs we’re targeting the user interface APIs. The same rules apply. We will move to the beta phase when we’re confident that we can move forward with just minor tweaks to the UI specific APIs.
Once we’ve been through a couple releases we’ll start talking about Release Candidates. When we’re comfortable with those we will do the 3.0.0 general availability release which will finally guarantee that no API will be changed or removed and the ABI will be stable until 4.0.0 (which I hope, will not take another 20 years).
The cadence of these releases remains to be seen, but I’m hopefully that they will be sooner than every three months, but time will tell as this is a volunteer project after all.
I hope this has cleared things up, and if you have any questions or comments please feel free to drop them there!