v3.0.0

[djmitche]

This new major version of Taskwarrior comes with an important change: the sync functionality has been rewritten entirely, and no longer supports taskserver/taskd. Instead, the recommended solution is a cloud-storage backend, although taskchampion-sync-server is also available. See https://taskwarrior.org/docs/upgrade-3/ for information on upgrading to Taskwarrior 3.0.

Note that this is a breaking upgrade: users must export their task database from 2.x and re-import it into 3.x.

The release consists of the following archives:

task-3.0.0.tar.gz (sha256 30f397081044f5dc2e5a0ba51609223011a23281cd9947ea718df98d149fcc83)
Release tarball. Use this to build and install Taskwarrior.

---

This discussion was created from the release v3.0.0.

[JD-Veiga]

[ryneeverett]

* or if you **use sync to your own server with `taskserver`** (upgrading server was not straightforward and does not work properly in my case),

Please note that taskserver has been unmaintained for years and has outstanding vulnerabilities.

* or if you **use `task undo` on daily basis** (it does not prove to be as safe as in TW2 for me).

Please open an issue if you have a reproducible example.

I highly suggested to try the new version in a sandboxed environment. Do not allow TW3 to make any change in your production data until you are sure that everything works smoothly (specially if you use synchronisation).

Much of your comment is good advice for any major release of any software that handles valuable data.

I really would like that TW3 can use plain text files instead of binary data for storing and for synchronising via configuration —plain text files was, by far, the most important point for using taskwarrior instead of other to-do programs.

This reminds me of reactions against moving away from paper. Yes, paper had some reliability and durability that isn't inherently guaranteed by digital data, but digital data can be stored and backed up reliably and we can do the same things faster and novel things that paper never could. Likewise with the transition to a real database.

Don't get me wrong, I'm sympathetic to staying with taskwarrior 2 for a while as taskwarrior 3 stabilizes and improves its backup/sync story. But I don't sympathize with insisting on a less powerful data storage format on principle.

[ryneeverett]

For a personal use, one single user, which is my case, a text file that you can modify directly can be probably better than a database in a binary format. I chose TW because of that.

From my perspective, manual database editing was a symptom of a database that is optimized for humans and not machines. I would suggest that perhaps all of the purposes for reading and modifying the text file database can potentially be better accomplished by taskwarrior itself when it has a real database. Operating at this higher level of abstraction should be a net benefit for the "single user" use case as well.

[djmitche]

Thanks for the comments here! I agree that 3.0 represents a change in direction for the project (hence the major version change). The costs and benefits of such a change always fall differently on different people. Thanks especially to @ryneeverett for highlighting some of the reasons for and advantages of these changes.

[ryneeverett]

A couple thoughts about the negative reactions against this release (not directed at anyone in particular):

1. An under-resourced volunteer-based open-source project is guided by the vision of the people who "show up". Years went by when anybody could have shown up and influenced the direction of the project. If you're happy to freeload on the assumption that somebody else will maintain the principles that you consider important you're eventually going to get burned. Beggars can't be choosers.
2. Everyone complaining about this release either downloaded and built it manually and did not read the release notes or received the update automatically through a package manager. I'm surprised a package manager pushed this release out so fast but that seems like the most reasonable explanation. There's no perfect solution to this but the blame for a major release containing breaking changes breaking your system should fall somewhere downstream of the project itself or there would be no way to ever make breaking changes.

[JD-Veiga]

They are users, not beggars.

[djmitche]

I'm sure @ryneeverett was using a common phrase, and not meaning to disparage anyone. Still, this is a moment of heightened tension for users and developers, so an extra dose of kindness is in order.

[eguiraud]

Everyone complaining about this release either downloaded and built it manually and did not read the release notes or received the update automatically through a package manager.

that was me: arch linux pushed v3 out as part of a normal rolling release updates last week. still, it would have been nice if the CLI from v3 had given me a heads up that the reason why suddenly all my task data was gone was that I missed the export/import step. taskwarrior used to give little version update tips through the CLI, this would have made for a nicer experience.

[ryneeverett]

@eguiraud Yes, that was a mistake which we're working to correct: #3342

[belkka]

BTW I use hate updating Arch...

[djmitche]

For a little more background, this project has been very quiet for about a decade, with some serious deficiencies especially in the sync support. Around 5 years ago, I and a few others started working on a re-implementation around a more reliable and secure data model - that was Taskchampion. The idea was to build this "in the style of" Taskwarrior, but not try to clone it in the details (command-line parsing, report formats, config, etc.).

However, after some discussion with the Taskwarrior devs, we decided that this amounted to a "fork" and the downsides of doing so outweighed the benefits. Instead, I began working on integrating Taskchampion into Taskwarrior, with the intention of keeping the CLI the same while replacing the data storage.

That was a heavy lift, and now we've achieved that with 3.0.0. With the very limited development resources available, we've had to scale back ambitions quite a bit, and that leads to some rough edges for users. I'm sorry about that, but it's the situation.

[ryneeverett]

Correct me if I'm wrong but -- from my reading of public conversations -- I think the piece missing here is that nobody else expressed interest and motivation to fix the outstanding issues with taskwarrior. The "downsides" were that taskwarrior would languish while the fork moved forward. There wasn't really a viable alternative vision, which is the context I think is missing in the criticism.

[djmitche]

I think that's a good summary. Also, there's an ecosystem around Taskwarrior, and the path we chose will hopefully re-invigorate that ecosystem by making it easier and more reliable to interoperate with Taskwarrior.

[iwyatt]

Nice work @djmitche !! Excited to give this a try!

[eguiraud]

Hi, thank you for you work on this release.

Like many others (judging from threads online) I was surprised to find out that self-hosting a sync server is not recommended anymore:

the recommended solution is a cloud-storage backend, although taskchampion-sync-server is also available

It's a sad day for me when the recommended solution requires storing my task data on google cloud (and it has to be google cloud as it's the only one supported).

Can you please elaborate on:

1. the state of taskchampion-sync-server with respect to cloud storage solutions: why are they not on the same footing, and the latter is recommended over the first?
2. I'm currently using the local sync option, and sharing the data.location directory between machines with syncthing. I understand that if I modify the task information at the same time from two machines there could be conflicts (I'm the sole user so that's very unlikely). is this way of syncing going to be supported going forward? in man task-sync it's not listed with the main options but only as a last alternative. unclear to me why man task-sync advocates for google cloud so strongly
3. as an extra, just out of curiosity, it would be nice if the devs could share some of the reasoning behind this choice (I didn't see it in the release notes): I understand it's less work to offload sync to third-parties, including all the security problems that come with it, but taskchampion-sync-server is a thing so I'm a bit confused

[ryneeverett]

Yeah, that makes sense regarding that particular concern. The broader concern I'd have with using syncthing is that, even with a single user, the only way to avoid sync conflicts is to always make sure your machine is synced before making any task changes, right? IMO that's a good reason for it to be a "last alternative".

[djmitche]

I agree with @ryneeverett that this solution (and similarly Git and other file-syncing solutions) should be a last alternative for syncing multiple task DB's. That's part of why we moved those options to the bottom of task-sync(5) under the label "ALTERNATIVE: FILE SHARING SERVICES". Any such solution has serious caveats that might result in data-loss if not handled carefully. Importantly, that's been the case in 2.x versions as well.

Hopefully we'll soon have enough supported sync options that such alternatives won't be necessary, but in the interim, people who understand the risks can continue to use them.

[stinovlas]

I still don't get this. What's the practical difference between google cloud and syncthing for the purpose of taskwarrior? They both just synchronize files. And if I do offline changes on two separate machines and then they both connect (regardless whether they connect to the google cloud or via syncthing), I have a conflict.

Or is the synchronization to the google cloud done in entirely different fashion? And if it is, is there a chance to get a general API that could be used by some open source self-hosted cloud implementations?

[ryneeverett]

@stinovlas The google cloud backend is not google drive and indeed has a different api. However the sync is done through a general protocol which does have an open source self-hosted implementation -- https://github.com/GothenburgBitFactory/taskchampion-sync-server.

[DDzwiedziu]

Hot tip for Syncthing, if one wants to share a DB: add version control to the share and hang tight.

I've found with syncing Firefox and a local-only Git repo for a Obsidian vault that sync conflicts are pretty common. For text files this is annoying, but manageable with a proper script. For binaries however it tends to leave you with files you can't easily compare (for an average user at least).

I've ditched the Firefox share because of this problem, which made the sync trigger too often (with inotify) and cause divergence and data loss at one point. And that Git repo is not a top priority.

[pmlandwehr]

Just got bitten by the automatic upgrade from 2.6.2 to 3.0.0 in brew today. Any possibility of adding back the old release to the channel so I (& others?) can run the export operation? (Was trying to build 2.6.2 myself this morning, but had no luck. Blame my old mac and old dev tools.)

[h0adp0re]

I managed to downgrade task temporarily by following this guide: https://dae.me/blog/2516/downgrade-any-homebrew-package-easily/

In a nutshell:

1. Download a pre-v3 formula file for task, I used the one immediately before: https://raw.githubusercontent.com/Homebrew/homebrew-core/affca0c7940b3c354d73b8d8b1210e2c02ebb285/Formula/t/task.rb
2. Uninstall task v3: brew uninstall task.
3. Install the previous version from the file: brew install task.rb.
4. Run the export command: task export > all-tasks.json.
5. Uninstall the older version: brew uninstall task.
6. Install v3: brew install task.
7. Import your tasks: task import rc.hooks=0 all-tasks.json.

Hope it helps :)

[thomassantosh]

Thanks so much! Just got impacted by this on a Mac. But these instructions helped to first downgrade, run the export commands and then get on the newer version.

[ddddavidmartin]

Thanks @h0adp0re, that worked a treat! Also to stay on the previous version you can pin it.

brew pin task

And it won't automatically updated until calling brew unpin task again.

[BigJayToDaIzo]

Also just got gutpunched by the arch package updating and having no way to export my tasks using 2.6.x to import into this 3.0 update. Now I have this annoying banner at the top of my reports:

This after a package update a couple weeks ago just made my task data disappear entirely with a demand that I run some sort of synch server, which I set up and started completely over on my data. I do believe this is a package maintainer issue less than a software maintainer issue, but it's still REALLY destroying my workday productivity today. I worry less about re-adding my existing tasks and MORE about losing things like burndown data and history.

With that said, I'm happy for the new major release and I'm happy that the activity is picking back up because this tool is CENTRAL to my staying organized. I LOVE IT! Thank you for your hard work! It's nice to see the Rust ecosystem penetrating the plugin market as well. I love Rusty apps and plugins!

[djmitche]

If you delete the *.data files in your .task directory, that warning will disappear. Alternately, you might be able to recover the data by starting a VM or a Docker image running a distro that still ships 2.6.2 (such as Ubuntu), copying the *.data there, and running task export. Then you'd get the history (and with it the burndown).

[djmitche]

I just made a 3.0.1 release to address some of the issues that were raised here and elsewhere. In particular, the release tarball now actually builds (I checked this time).

[ddddavidmartin]

Interesting to see major changes happening! What is the best way to stay informed on what's going on? I don't mind moving forward but would like to wait for some mobile support first.

Got caught out by this upgrade by a homebrew upgrade as well and am sticking to the previous version for now. I fear there may be as many sketchy task setups as users probably. I'm self-hosting and using an Android app that hasn't been updated in 8 years. But overall it works. One learns to work around issues :)

[djmitche]

For better or worse, this discussion page is currently the most active place I know of.

[wrashi]

Just wanted to say thank you to @djmitche & team for the update to TaskWarrior! Homebrew pushed the update to my machine yesterday, but a Nix 2.6.2 version is my active instance, so I fortunately didn't get bitten by the problems others did.

Is there something I can do to help with letting users know about updates so that we surprise people less?

[wrashi]

TBH, I really don't know :). I'm generally not a big community guy. But having written a book about TW and am planning a course/coaching experience, I'm really excited about the move to a database and updated server options. I'm also willing to try to participate in and support some kind of official community. TW has been so helpful for me in the last 15 years I think it's only right that I try to give back.

[djmitche]

I had no idea there's a book! That's so cool!

Here are some ideas for ways to help out -- some more concrete than others..

• Find and join the various TW community areas, and gently redirect participants to a single place for authoritative information. I'd prefer that be this repo, but "single" is the critical word.
• Think about ways to ensure project continuity, to avoid issues like O, Project Activity Where Art Thou? #2338. Maybe that means some kind of governance structure? That's tough to do without making more work for the already-too-few maintainers. There are some books out there on the topic such as Karl Fogel's "Producing Open Source Software". Organizations like Software Freedom Conservancy or Apache Software Foundation nominally serve this purpose, but more from a business-continuity perspective (Who holds copyright when a maintainer disappears? Who can see and decide how project funds are handled?). They don't actually provide additional engaged project maintainers!
• Revive and refine the RFC process. I didn't use this process for the changes leading to 3.0.0 partly because there wasn't anyone to Request Comments from, or any clear process for soliciting those comments and knowing when they were complete. A lot of things I did early in my interactions with TW felt like yelling into the void, and eventually I stopped yelling.
• Improve processes for people to navigate the world of Taskwarrior integrations. https://taskwarrior.org/tools/ is generated automatically, and while it has a huge list, a lot of those are incomplete or unmaintained, so there's a lot of depressing noise in the signal. Could we do a better job? Maybe we could make up some kind of transaction: maintainers of integrations can get their integrations listed on taskwarrior.org if they participate actively in the project governance. I don't know, just thinking out loud here.
• Establish a pre-release testing group. Having a few dozen people willing to build, install, and smoke-test the new version in a timely fashion would help suss out both big issues (having all your tasks disappear is frustrating!) and small (Remove debug print #3389).
• <<Your ideas here!>>

[wrashi]

Haha! Yes, you found me! The material is complete, but not quite done (proofing, code improvements, etc.). My goal is to finish v1 this summer in time to advertise for NaNoWriMo.

Your ideas are excellent! Thank you very much. The next few days are packed rather full, but I'll take those away, think about it and commit to 1. I'll circle back here on Saturday or Sunday to let you know what I can think I can take on. Perhaps at that time we can think about first steps and direction. You seem to know where community is, or at least was, and might be revived.

[djmitche]

I should also add, maybe we should have a periodic video meeting. I'll make a new discussion topic to talk about that.

[wrashi]

Hey @djmitche, as promised I've done some thinking about getting involved in the TaskWarrior community.
I really like the idea of doing a regular video meeting.
I've posted my proposal in the new discussion thread you opened for that, but just wanted to close the loop here.
#3403 (comment)

[BigJayToDaIzo]

If you delete the *.data files in your .task directory, that warning will disappear. Alternately, you might be able to recover the data by starting a VM or a Docker image running a distro that still ships 2.6.2 (such as Ubuntu), copying the *.data there, and running task export. Then you'd get the history (and with it the burndown).

I thank you for your help but I managed to roll back to 2.6 to do a task export and then reinstalled latest for the import, deleted the *.data files and things are running smooth as heck now! I even managed to pull the old tasks that were 'lost' from the prior update somehow. Really rather easy (in comparision to losing data and starting fresh) in the end after the big panic, but for those not comfortable with building from source and dealing with package dependencies it could be a very intimidating process. In the end my favorite organizational tool on the planet is back to full operation. Thanks again for your hard work!

[DDzwiedziu]

Quick thought: maybe, due to incompatibilities, the main executable and base config directory could be named task3? This could allow the two versions to coexist for a migration.

[djmitche]

This might have been an option for distrbutions packaging the app. Distributions sometimes do this, e.g., with postgres or python.