As you may have read in the previous post, there have been quite a few issues with Lightning 2.6.x. I wanted to explain what happened and what we can do to avoid these issues in the future.
The Lightning build process is closely coupled with Thunderbird. Every time Thunderbird does a release, we get builds for Lightning for free. This means we mostly depend on them doing a release, otherwise I have to patch the final builds manually. This is a little more work. Luckily, each of the releases between 2.6 and 2.6.4 have been done together with a Thunderbird build.
Google Calendar Issues via CalDAV
Just before Lightning 2.6 was released, we made some last minute changes to accomodate for the fact that Google Calendar had changed their CalDAV URL. Not only that, they also implemented a specification for faster synchronization of CalDAV. We already supported this specification, but only an older version. A quick fix was done to take care. In total, were some authentication issues and an error loading calendars. We knew we had to release a 2.6.1, but we didn’t know it had to happen so fast…
Version compatibilitiy issues
When Thunderbird 24.0.1 was released, Lightning 2.6 did not work on Linux. The reason for this was a regression in the Mozilla Platform around Thunderbird 23. The binary component we have was built with a specifc compiler flag with a parameter that was too strict. It bascially said “this binary component is only for version 24.0.1”. The fix was easy, change it to “this binary component is for version 24.*”, but it took a while for that fix to be completed and admitted to all branches. Lightning 2.6.1 was quickly released as a workaround specificly compatible to Thunderbird 24.0.1, Lightning 2.6.2 was needed for Thunderbird 24.1.0.
Another problem why this was so hard to figure out for users is that some Linux distributions decided to skip the minor releases and only do 24.0, 24.1.0, 24.2.0 and so on. There were complaints because the latest Lightning version wasn’t working, when 24.1.1 was missing from the distribution repositories. We still needed to release consequent Lightning versions though, otherwise users using the stock builds would complain.
Lightning 2.6.3: Issues with CalDAV
Unfortunately, one of the patches for 2.6.1 had an error in it. We decided there needs to be a quick fix, and it was just in time for Lightning 2.6.3. The binary compatibility bug had been fixed by now, so this should also be the first version that is compatible to any version of Thunderbird 24.1.1 and up.
Lightning 2.6.4: Yet another one
Now this is the release that really annoyed me. First of all, I did a bad job on one of the patches. The other one was a minor issue with servers that don’t have a certain XML element in their response. These are the kinds of issues we could have easily figured out before the release with more and better unit tests. We might have even saved another release.
Conclusion
We probably could have known about all of these issues beforehand if we had tests to catch them. Just running the any of the tests using the build machinery would have caught the binary compatibility issue. If we had at least some manual tests to test CalDAV servers, we could have started them for a few public demo servers and caught all of the CalDAV regressions. Both of this has been on my list for quite some time, but given all the other things coming up I never got around to it.
Integrating the tests with the build system is unfortunately something only someone with Mozillians trust can do, but if you want to help us write some unit test, that would be marvelous. The cool new thing to use is promises and tasks, which allow writing really easy to read asynchronous code. I have some demo code thats not quite working but is ready for someone to pick up.
If you want to help in some other way, please contact me! Even if you are not a developer, there is a lot that can be done for someone with a little initiative.