Lately I’ve been doing design and prototype work for Typica 2.0. That’s not going to be released soon. I’m looking at probably some time next year and there will still likely be 1 to 3 more releases in the 1.x series before then, but there are some changes that I want to make that would be too disruptive to consider without a major version bump. Or rather, the changes will take me too long to be finished before I’ll want to have a new release out. There are several such changes that I’ve been building up and I think now is a good time to start putting all of that together.
The database changes are particularly interesting. If you look at Typica’s database design, it really hasn’t changed very much over the years. Some minor changes have been made, but the initial design has held up surprisingly well. But experience working with that and features that I want to add have revealed that I didn’t go far enough with certain guiding principles I had in that initial design while other approaches that I tried have made some operations more difficult than they should be.
Things will look very different in the new database, but I have years of data in my current database and I don’t intend to lose any of that in this transition. I also expect that anybody who was doing anything fancy with the database outside of Typica should be able to create views that are equivalent to the older design if they really need to. From the perspective of someone using Typica the database changes should be pretty much invisible except in terms of new features the changes enable.
With the new design, I’m taking the opportunity to add support for SQLite3. That’s tricky because there are a lot of PostgreSQL features that Typica currently uses which don’t really exist in SQLite without resorting to ugly hacks, but so far that hasn’t presented much of a problem with the new design. This is a move to make it easier to get started using Typica. I don’t really understand why installing PostgreSQL is a deal breaker for some. You download and run an installer, click Next a bunch of times since the defaults are pretty sane, and pick a password at the end. Still, a lot of people just want something that’s only going to be used on a single machine for a limited set of features where PostgreSQL is overkill for the problem, so I can remove that dependency while still keeping most of the feature set for people who choose not to bother with it. I intend to make it very easy for people to switch back and forth so anybody who is using Typica now and doesn’t really need PostgreSQL can switch to using SQLite and someone who wants to enable work flows that don’t make a lot of sense without PostgreSQL can switch to that when they need to. Might make backups a little easier.
I’m also being a bit more careful to write use documentation as I go with this, so maybe 2.0 can launch with a complete manual (other than the source code) available. Hard to RTFM if the section you need was never written.
In mostly unrelated news, I was recently interviewed for an article that I guess will be in the next issue of Roast Magazine. I haven’t seen how that’s going to be edited, but it should be pretty good. Be sure to watch for it.