Happy New Year!
It is my firm belief that it is the community, and not the code, that makes an open-source project what it is. With that in mind, I’d like to thank you, the community around Prosody for making the project what it is. Whether you contribute code, help test nightly builds, develop packages, support others in our chatroom and mailing lists, or simply report bugs so that we can fix them - you have helped shape the project, and helped make the project better for everyone. For that - thank you!
As well as reflecting on what we have to be grateful for, there is no better time than the start of a new year to look at the past and what we have achieved, the present, and of course look forward to the future. First, let’s start with our achievements over the past 12 months.
The obvious highlight of 2018 was the release of Prosody 0.11, which saw the release of many highly-anticipated features. But behind the scenes there have been many other important changes in the project.
We completed the migration of the main server that powers the prosody.im website and XMPP service to a new machine. We also received a dedicated build server, donated by Bytemark, on which we set up our new CI service.
Test, test, test
Before digging into the subject of tests, we need to put things in perspective. The Prosody 0.10 branch had approximately 1500 lines of tests. They used a custom test framework, they did not run regularly, and they were not a part of our daily development workflow. Many of the tests were unmaintained, and did not pass, even in releases.
In comparison, the Prosody 0.11 branch is now using a standard test framework (busted), and has nearly 5k lines (and growing!) of maintained and passing tests that are automatically run in multiple target environments every time we push new changes.
In addition to these unit tests, we have now added integration tests to the mix, which allow us to record and replay XML streams and verify the results against a running Prosody instance in an automated manner. This has proven invaluable for testing compliance with XEPs and interoperability with actual clients. This is actually really exciting stuff, and we’ll be doing a deeper dive into how this works in a future blog post!
Another major change to our development workflow has been the introduction of linting/static analysis. The excellent luacheck tool has allowed us to find and fix many code issues earlier in the development process. Our policy is for all new code to pass luacheck, and we have made significant progress with bringing all existing code up to standard. This means all our core code now passes, and most of our plugins. This is enforced by our CI.
As a bonus feature, we also automatically run luacheck against community modules, and flag modules that have code quality issues.
While luacheck, as with most static analysis tools, throws up many false positives (i.e. bits of code that may look incorrect, but are actually fine), adopting it as a standard adds a little more confidence and helps prevent subtle bugs from creeping in to code during development.
2019 and beyond
Work will continue towards our next major release, which includes finalizing the async API (the initial pieces of which are already present in 0.11), a replacement for our telnet console, long-awaited SNI support and revising how we handle “direct TLS” connections (as in XEP-0368). Besides these primary goals many other things are likely to slip in along the way.
Community survey and feedback
We are always discovering new people and projects using Prosody that we were unaware of. We do not have any kind of tracking in Prosody, and it is impossible for us to know how many deployments there are worldwide. It is therefore easy for us to miss out on feedback from users who are not actively engaged in the project, but whose feedback is just as valuable to us.
With this in mind, we have drafted a 2019 community survey, which we would love you to fill out. It will help us form our roadmap for the releases ahead.
We also have a new email address, email@example.com - we’d love to hear your thoughts and comments on anything related to the project.
We will continue to work on project infrastructure this year. In particular we are aiming to retire our current build server on AWS and transition its responsibilities to the new server that is hosting our CI. This will make it easier for us to add new architectures, distributions and build targets (e.g. container images, etc.). If you’re interested in nightly builds for a particular platform that we don’t yet support, let us know!