3.0 Status Update

[djmitche]

What follows is a brief summary of what is going on for the next (major) release of Taskwarrior, from my perspective.

Changes

The major changes in 3.0 are around how task data is stored and accessed. Locally, task data is stored in a more reliable format (SQLite). Sync is more reliable and task data is encrypted so that server operators cannot read it. All of this is accomplished by using Taskchampion, the new "core" of Taskwarrior. The change has a few future-facing benefits, in addition to the immediate benefits above: other applications can embed Taskchampion to integrate with Taskwarrior or automate task operations; and it is written in a language (Rust) that is attractive to new contributors and may help to rejuvenate the Taskwarrior development community.

Status

The bulk of the implementation is complete: Taskchampion can store and sync task data, and Taskwarrior has been refactored to use Taskchampion. On a personal level, I've been using the newest Taskwarrior at work for almost a year, with no difficulties.¹

A few things are still not ready, though.

Some existing functionality isn't yet supported, notably the "task history" in task info is gone (removed in #3060) and task undo no longer gives a summary of what is undone. There's discussion of how to fix those (#2928).

The sync story is barely an MVP. The new taskchampion-sync-server is even more bare-bones than taskserver (which it replaces), and is missing some peformance-related functionality (#2877, and it only supports a SQLite backend). It would probably be difficult to deploy "for real". There is some discussion of fixing the space-saving issues, and also discussion of using commercial cloud services' object storage as an alternative (#3185). This would likely be far cheaper than running the sync server on a VM, and potentially easier for less-technical people to set up. There is also discussion of improvements to the privacy of task data (#3183), although it's not clear that is required for a 3.0 release.

There's quite a bit of clean-up of documentation to do, as well, to clarify the boundaries between Taskwarrior and Taskchampion and how to integrate with Taskchampion (#2868).

Nice-To-Haves

We've set a few things to the side for the moment, to try to focus on getting to 3.0. However, we may work on these anyway if there's interest or if they prove useful.

• Taskchampion would probably be best handled as a distinct "project", in its own repo, with its own releases, and treated as a dependency of Taskwarrior (src/tc/rust doesn't correctly depend on taskchampion/* #2887, Dependabot needs to update src/tc/rust/Cargo.*, too #2994, Harmonize Taskwarrior and TaskChampion changelog generation #2888, Use a codespace and simplify the "getting started contributing" docs #3141).
• The C API for Taskchampion is functional but should probably be reworked by someone with more experience, maybe using more common tools like cxx (#3059 is related -- probably ffizz is a bad idea?)
• The Rust API in Taskchampion could use a bit of polish that would probably result in compatibility-breaking changes (#3058).

Progress

I've run out of steam on this project after a few years' work. I get excited from working with other people, so that's where I've found myself spending time -- whether that's working with new folks on good-first-bugs or co-designing things with more experienced developers. So, I don't have any timeline for the "not ready yet" bits. To my knowledge, there isn't any ongoing development work by other maintainers at this time.

I think the quickest path to 3.0 is for someone to do the bulk of the work on a cloud-service backend (#3185), and someone (else) to do the bulk of the work implementing and exposing operations (#2928).

[1] I'm not using the sync functionality, though -- it's not required or useful in this context.

[gour]

Hello Dustin,

Thanks a lot for your report!

Although I've several times tried other applications (e.g. org-mode), I regularly return back toTaskwarrior and now even plan to use it along with Timewarrior. 😇

I can live without taskserver, although it would be a nice one to have, but I wonder what is the status of "recurring overhaul" which was supposed to be one of the main 3.0 features?

Sincerely,
Gour

[djmitche]

I don't know of anyone working on that over the last few years.

[gour]

I don't know of anyone working on that over the last few years.

So, it looks that the "TaskChampion" has become 3.0's theme instead of "Recurrence Overhaul". 😎

Well, as long as it gives new life to Taskwarrior, it's fine. 😉

[djmitche]

If someone is working on it, or starts to do so, then we can include that in 3.0 -- or 4.0!

[IDDQD69]

Build version 3.0 today and it seems to be fine :) Really exited to see new taskchampion-sync-server someday!

[ryneeverett]

I think the quickest path to 3.0 is for someone to do the bulk of the work on a cloud-service backend (#3185), and someone (else) to do the bulk of the work implementing and exposing operations (https://github.com/GothenburgBitFactory/taskwarrior/issues/2928).

Maybe a silly question but why are these release blockers?

[djmitche]

It's a reasonable question, but both of those address what is otherwise a regression in functionality: sync support and task history.

[ryneeverett]

Ok, I get that for task history but I'd question whether sync support is really a regression. AFAIK all the "public" taskd instances are now dead so that doesn't seem like a fair bar to compete with. Isn't self-hosting the current sync server comparable to self-hosting taskd?

[djmitche]

You're right that self-hosting taskd is not easy, but I think the current taskchampion-sync-server is even worse. An alternativ to the cloud backend would be to improve the sync server.

[msnspk]

Is the ability to store Taskwarrior data as text/JSON going to go away with the next release? I understand the benefits of using SQLite to store data, but I prefer to use Git to back up, sync, and version control my Taskwarrior data. Using Git has always seemed like the easiest method to sync tasks between computers, versus having to set up tasksever (or Taskchampion).

But using Git to sync and version control a binary database file is almost pointless, so I would prefer to keep my Taskwarrior data in plaintext/JSON that Git works well with. Will that be an option in future releases?

[msnspk]

Thank you for the information. So just to be clear, the export command supported by the current version of Taskwarrior will be deprecated or removed in the next release?

Also, I want to emphasize that while I use Git to sync Taskwarrior data between devices, my primary reason for using Git with my Taskwarrior data is to have a very simple and reliable backup solution. I should have specified that earlier, my apologies.

Being able to version control my Taskwarrior data, see its history of changes, and easily fix anything with well known commands, gives me a lot of confidence to experiment with Taskwarrior in ways I wouldn't otherwise. For me, Git has just been the all around best solution for backing up my Taskwarrior data.

If, in the next release of Taskwarrior, task data is no longer available in a text format and the export command is removed, then I will probably write my own solution for exporting the data to a text format, so that I can keep backing it up (if not necessarily syncing it) using Git.

Considering all that, I have one more question:

The current version of Taskwarrior has the import command. Are there any plans to offer a version of this command in a future version of Taskwarrior, and would that command accept data in any other form than a database file (such as JSON?)

[ryneeverett]

I can't answer your question but I do think your line of thinking around import/export might be a better track than my storage/server ideas. I do think if this is going to happen though, the effort would be better put into implementing import/export within taskwarrior than in an external tool. I'm not sure the database format is necessarily supposed to implement a stable API but a json export would take care of implementation details (e.g., applying operations).

[djmitche]

import and export are still supported, with the same format as 2.x.

[ryneeverett]

I wonder if we were too hasty to kill off the "VCS backup" documentation in f2c8a23. (context: I believe deleting it was my idea/suggestion.) It seems like it's still viable if you track export/import json rather than the new sql database itself. Given the current difficulty/complexity of sync server deployment, reliability concerns, and the fact that use of the sync server eliminates undo operations, it seems like there might still be good reasons to choose this method. Maybe we should re-introduce it with some updates?

[djmitche]

Yeah that seems like a good idea -- whether in the manpage or on taskwarrior.org. I don't quite understand how it would work so I can't write that particular doc :)

[djmitche]

I made a project to track this. Please add any other things you think are blocking a 3.0 release!

[ryneeverett]

The link is 404 and I can't find it. :)

[djmitche]

Only organization owners can change project visibility

Ugh, thanks Microsoft. Paging @tbabej or @lauft!

[tbabej]

Very weird to restrict at such high privilege level. Flipped to public, it should work now!

[djmitche]

We are nearing the end of the 3.0 project. I'd love to hear about other issues that might be blocking a 3.0 release!