The march towards a first beta...
I'm long overdue for another official post about the status of the LogicMail 2.0 project. So far, most of my commentary has been scattered between the forums, ticket system, mailing lists, and private E-Mails. As such, I think its about time I explained where everything currently stands.
As many of you have observed, I've been working towards a 2.0 release for far too long. There are really three main reasons for this:
- 2.0 really is significantly more complex than 1.x
To put things in perspective, using the SLOC metric (as calculated by this tool, the final 1.1 release comes in at 13,579 SLOC. Meanwhile, as of today, trunk is at 31,427 SLOC and growing.
- I do this as part-time adventure
A few hours here and there is plenty for following up on E-Mails, fixing minor bugs, or adding small features. However, the bigger stuff requires me to be able to dedicate whole days of development time. While I can do this on occasion, I am limited in how often I get the chance.
- As a direct side-effect of taking so long, the following additional things tend to happen:
- More time is spent dealing with end-user issues and requests
- New BlackBerry platform features come out that I want to take advantage of
Despite everything mentioned above, I am optimistic about being able to finally get 2.0 to the beta stage some time this year. The end is in sight, and I actually know what else needs to get done. In short, the following are my must-haves for 2.0 being "feature complete":
- Various performance and memory management enhancements (connection read/write #221, IMAP parsing #222, cache loading #213, memory management #212)
- Incremental loading of mailbox data (#211)
- Running in the background and auto-fetching new data (#79, #78)
Anyone who follows the development builds has probably noticed some of the slush after build [build:199] and hopefully ending in build [build:202]. This is where I implemented #221. It has made actual network loading much faster, but has had the side effect of making the post-processing seem slower. Hopefully #222 (a work in progress) should fix this.
Now, we all really want 2.0 to actually get to a beta release sometime this year. As far as I'm concerned, the beta milestone is where the application is feature-complete, and most of the more major bugs are fixed (and/or well documented). In order to get there, I really need to focus on the core features. This may mean that every little user-request or issue won't get acted upon immediately. However, if they are documented in well-written tickets, they can still be mostly addressed prior to a final 2.0 release (or moved over to 2.1).