…but of course there is is a release for Thunderbird 38! Since the release date for Thunderbird has been postponed and in the meanwhile Firefox has released 38.0.1, Thunderbird will also be released as Thunderbird 38.0.1. Since the Lightning version is automatically generated at build time, we have just released Lightning 4.0.0.1. If you are still using Thunderbird 31 and Lightning 3.3.3, you will be getting an update in the next days.

The exciting thing about this release is that Lightning has been integrated into Thunderbird. I expect there will be next to no issues during upgrade this time, because Thunderbird includes the Lightning addon already.

If you can’t wait, you can get Thunderbird in your language directly from mozilla.org. If you do happen to have issues with upgrading, you can also get Lightning from addons.mozilla.org. The latest Seamonkey version is 2.33.1 at the time of writing, you need to use Lightning 3.8b2 in this case. For more information on compatibility, check out the calendar versions page.

As mentioned in a previous blog post, most fixed issues are backend fixes that won’t be very visible. We do however have a great new feature to save copies of invitations to your calendar. This helps in case you don’t care about replying to the invitation but would still like to see it in your calendar. We also have more general improvements in invitation compatibility, performance and stability and some slight visual enhancements. The full list of changes can be found on bugzilla.

If you are upgrading manually, you might want to make a backup. Although I don’t anticipate any major issues, you never know.

If you have questions, would like support, or have found a bug, feel free to leave a comment here and I’ll get back to you as soon as possible.

It’s that time of year again, we have a new major release of Lightning on the horizon. About every 42 weeks, Thunderbird prepares for a major release, we follow up with a matching major version. You may know these as Lightning 2.6 or 3.3.In order to avoid disappointments, we do a series of beta releases before a such major release. This is where we need you. Please help out in making Lightning 4.0 a great success.Time flies when you are preparing for releases, so we are already at Thunderbird 38.0b3 and Lightning 4.0b3. The final release will be on May 12th and there will be at least one more beta. Please download these betas and take a moment to go through all the actions you normally do on a daily basis. Create an event, accept an invitation, complete a task. You probably have your own workflow, these are of course just examples.

Here is how to get the builds. If you have found an issue, you can either leave a comment here or file a bug on bugzilla.

Scroll down to the “Developer Channel”, expand the box and click on the download button

You may wonder what is new. I’ve gone through the bugs fixed since 3.3 and found that most issues are backend fixes that won’t be very visible. We do however have a great new feature to save copies of invitations to your calendar. This helps in case you don’t care about replying to the invitation but would still like to see it in your calendar. We also have more general improvements in invitation compatibility, performance and stability and some slight visual enhancements. The full list of changes can be found on bugzilla.

Although its highly unlikely that severe problems will arise, you are encouraged to make a backup before switching to beta. If it comforts you, I am using beta builds for my production profile and I don’t recall there being a time where I lost events or had to start over.

If you have questions or have found a bug, feel free to leave a comment here.

Together with Thunderbird 38, we will be releasing Lightning 4.0. Both of these releases are not beta versions, but similarly major releases like Lightning 3.3, Lightning 2.6 and their respective Thunderbird counterparts.

We have about 11 weeks left until the release will be final, and while the developers are doing their best to make sure features are stable and there are no regressions, its time to do some translation work.

If you have been missing your language in Lighting in the past, maybe this is a good time to contact the l10n team of your language and express interest to translate Lightning. While the initial hurdle may be large, there are usually not many changes in strings between Lightning releases. If you are lucky, someone had already translated part of Lightning in the past and all you have to do is update your locales. The translation process is fairly simple and can be done using your favorite browser.

If you are already part of the Localization teams, this is the time to head over to mozilla.locamotion.org and translate the remaining Lightning strings. Once you are done translating and the changes have been pushed to the localization repositories, please head over to the Thunderbird l10n dashboard (not the Calendar Dashboard) and sign-off the latest change. Make sure you are signing off the later changeset of Thunderbird and Lightning, as only the newest sign-off will be used.

Should you have any questions, please feel free to send me an email or comment on this post and I will get back to you as soon as possible.

The one thing I like best about the Google Summer of Code is that it gives us an opportunity work on cool new features I never have time for on my own. Also, its a great opportunity for students to learn about working on a large-scale project and prepare for real life work, which is very much different than the smaller projects I remember from my university. Students that have stayed with us even after the Summer of Code have proven themselves invaluable, showing spirit and enthusiasm for an open source project like the Mozilla Calendar Project gives me a warm feeling in my heart.

This year, we have proposed two projects: Introducing Calendar Accounts and Resource Booking Improvements. As the projects have been available on the wiki for a while (sorry for not blogging about this earlier!), we’ve already had the one or other student interested in applying. However, that doesn’t mean there isn’t any room left for a fine candidate like you!

In the first project, Introducing Calendar Accounts, the goal is to improve our backend layer to move from a flat list of calendars to a hierarchical list with calendars grouped by the accounts they belong to. Aside from the benefits this gives us w.r.t. avoiding code duplication and ugly hacks, it will open Lightning to a load of new features related to accounts, for example notifications if a new calendars was added to the account or improved support for authenticating to calendars on one server with different credentials.

Second, we have proposed a project on Resource Booking Improvements. Right now, our invite attendees dialog is fairly simple and only allows entering email addresses and seeing their free/busy status. What is missing is an easy way to invite resources and rooms, for example when you want to book a conference room for your meeting. There is an inconspicuous feature that allows changing an attendee to a resource entry, although there is no real value in doing this aside from sending more correct data to the calendar server. The user still has to remember the virtual email address associate with the conference room. With this Summer of Code project we want to allow any kind of calendar provider to be able to specify how to search for rooms and resources. Certain CalDAV servers support searching for these entries using custom queries, the goal for this project is mostly to support those servers.

If you are interested, please do get in touch with me, either via email or on irc.mozilla.org, where my nickname is Fallen and I usually hang around in #calendar. Should I not be around, redDragon (a former GSoC Student, by the way!) will be there to help you.

First of all, I’d like to apologize for not adding in new blog posts once in a while. There have been a few topics I could have written about, but I never got around to it. The consequence is that there will be a few posts in succession now, I hope to be better about this in the future.

In this post, I’d like to tell you a little bit about the changes to the Provider for Google Calendar that have taken place in the last months. With due prior notice, Google has shut down version 1 and version 2 of the Google Calendar API. The previous version of the Provider for Google Calendar, version 0.32, was still using the API v1.

The changes to the API were fairly substantial, so I took the opportunity to rewrite large parts of the Provider to use new JavaScript features and generally make the code more readable. I also added some new features, including:

Support for tasks using the Google Tasks API

A very user friendly new calendar wizard, no need to enter the XML url.

Offline support by default, with no need to disable it.

Support for the activity manager, sync progress is now shown in status bar

Better (albeit not perfect) support for accepting invitations

Allow setting default reminders

Compatibility to Postbox 3

As such drastic changes are a common source for regressions, I went through 10 rounds of pre-release testing and got some very helpful input from those who commented on the bug or sent me an email. There would have been substantially more issues without these folks, so thank you very much! In the last round the amount of issues was down to a level where I felt comfortable releasing the Provider to the world.

When I release version 1.0, something inevitable happened: nearly 300,000 users find more issues than 140, so I had to do a few additional releases to fix more major issues. The new API version imposes limits on the number of requests being made, so one of the first issues I had to overcome was gaining more quota. Thanks to the fantastic folks at Google I was able to solve this issue using a combination of code changes to reduce the number of requests and also higher quota limits. Here is a roundup of the other issues:

Version 1.0.1

Calendars were incorrectly migrated from 0.32 to 1.0

Users who disabled cookies could not use the login dialog

Attendees added from Hangouts were incorrectly shown

Version 1.0.2

Added descriptive text to the new calendar wizard to make it easier to understand for users who were used to entering the XML url.

Refresh intervals smaller than 30 minutes were prohibited due to quota issues

Back button in new calendar wizard no longer causes double-subscriptions

Synchronizing no longer blocks UI thread

Calendars no longer get disabled when in offline mode

Use application locale when showing OAuth window

Fixed an invalid timezone definition for the start time

Provider no longer ignores default reminder settings

Version 1.0.4

Notifications are now correctly sent when modifying events

Fixed creating events without an organizer but with attendees

Fixed an error in the attendees dialog with “entry.interval is undefined”

Correctly create events in UTC timezone

Wait for parsing to complete before completing synchronization

Fix some internal issues and a compatibility issue with Thunderbird 24

Improve invitations handling

Google login popup now has a description as to why its required

Fixed setting default alarm props on calendars without default alarm

Task lists now work for calendar entries without a calendar (regression)

Outdated client message shown when using obsolete token

In retrospect, there have been a lot of complaints, but on the other hand a lot of people have noticed how important this addon has become for them. Many have shown their gratitude by sending a donation via the addons page. I hope that version 1.0.4 fixes most of the issues, there are just a few more issues reported. If you continue to experience difficulties, please send me an email or visit the support forum.

Thanks to the wonderful folks at Linagora, I was able to spend the last three days at the Calconnect XXXI meeting in Bedford, England. The goal of this meeting is to get server and client vendors together in a room both for ad-hoc testing and discussions on calendaring standards.

Before arriving, I’ve set myself the goal to go through a big list of bugs that have been sitting around in our CalDAV component to see if they can be resolved. It turns out that I was able to close 48 of the 76 bugs I had picked out:

A good amount of the bugs I’ve resolved were sitting and waiting for any one of our contributors to reproduce with a specific server. This is often a problem because the time it takes to set up and configure the servers is time consuming. The great thing about being here at Calconnect is having a testing instance most of the reported servers readily set up. Not only that, but engineers from the respective servers are sitting together at a table and can answer any questions that may arise, or comment on potential bugs that have been fixed in later versions.

The other category of bugs are support issues, duplicates and bugs that haven’t received an answer from the reporter. These could have been found outside of Calconnect, but its still a good opportunity to take the time to handle these.

Eight of the remaining bugs already have a patch attached, four of them were created while I was here. There is also a new feature coming up that makes it easy to share calendars with other users directly from Lightning. This requires the server to support caldav-sharing, for example the Apple Calendar and Contacts Server and fruux.com.

Note: The ugly add button will be replaced by an icon. The email addresses are editable.

In the next few days we will be going on to the standards discussions. I am actively involved as the chair to TC-API, a technical committee dedicated to producing an abstract calendaring model that ensures that vendors integrating calendaring into their products are aware of the implications of calendaring and scheduling, hopefully resulting in better interoperability in the future. Another goal we have is to find a common understanding for a REST API that is geared towards webpages, which may become a standards document some day.

There have also been a lot of changes in the backend that are not visible to the user. This includes better testing framework support, which will help avoid regressions in the future. A total of 103 bugs have been fixed since Lightning 2.6.

When installing or updating to Thunderbird 31, you should automatically receive the upgrade to Lightning 3.3. If something goes wrong, you can get the new versions here:

Should you be using Seamonkey, you will have to wait for the 2.28 release, which is postponed as per this thread.

If you encounter any major issues, please comment on this blog post. Support issues are handled on support.mozilla.org. Feature requests and bug reports can be made on bugzilla.mozilla.org in the product Calendar. Be sure to search for existing bugs before you file them.

Addons Update:

There are a number of addons that have compatibility issues with Lightning 3.3. The authors have been notified and a few first fixes are available:

Calendar Tweaks: This addon causes constant flashing and makes Lightning unusable. The author has been notified and has released version 6.0 which shoul fix all issues. Plase notify him in case there is more trouble.

Thunderbird and Lightning do major releases about every 42 weeks and by now there are only 5 weeks left until Thunderbird 31 will be released. Your matching calendaring extension version is Lightning 3.3. Betas for both products are available and now its up to you: we need all the manpower we can get to make sure there are no regressions and everything still works as expected. Over a million active daily users will thank you for this!

To get started, download the beta builds and follow the standard installation procedure.

There is one known issue if you use a localized version of Thunderbird and Lightning. Certain locales have not been fully translated, but are included in the beta builds nevertheless. We will fix this issue for the second beta build soon.

I have noticed a few reports that Lightning 2.6.4 is not working with the Debian variant of Thunderbird, called Icedove. Together with one of our users (thanks Arie!) this was reported to the Debian package maintainers.

There are slight differences in how Icedove and Thunderbird are compiled, the result is that the Linux symbol versions required are different. The maintainers are working on fixing this, in the meanwhile all you need to do is make sure you are using only one source for the packages:

If you are using Thunderbird from mozilla.org, make sure you are using Lightning from addons.mozilla.org. You can install it into /opt if you don’t want to conflict with your Debian packaging system.

Unfortunately, this difference in compilation has cost us some negative reviews. If everything is working for you or this post has helped you to use the right versions, please show some love and write a review ♥.