Upgrading to 3.0 broke everything

[kensmith]

Upgrading from 2.6 to 3.0 broke everything in my taskwarrior setup. I'm self hosting taskd and syncing across multiple Linux machines and Android Foreground. Until upgrading, everything was great.

• task list no longer shows any tasks. When I look in $TASKDIR/pending.data, the tasks are all still there. Ditto for /var/lib/taskd/orgs//tx.data. Everything is still there
• task sync yields "No sync.* settings are configured." This is coming from

  taskwarrior/src/commands/CmdSync.cpp

  Line 91 in 3e41fb6

  throw std::string ("No sync.* settings are configured.");

  indicating that I need to set up sync.server.origin etc.

I barely have the enthusiasm to unbreak my configuration by trying to figure out the new config to make sync and task listing work again. I'm astonished that this breaking change was released without backward compatibility. I'm likely going to abandon Taskwarrior but in case you want to try to repro my case, here is a redacted .taskrc.

data.location=~/.local/task
include no-color.theme
news.version=2.6.0
report.next.limit=0
report.long.limit=0
report.list.limit=0
report.ls.limit=0
report.minimal.limit=0
report.newest.limit=0
report.oldest.limit=0
report.active.limit=0
report.completed.limit=0
report.recurring.limit=0
report.waiting.limit=0
report.all.limit=0
report.blocked.limit=0
report.full.limit=0
report.next.limit=0
taskd.server=redacted:53589
taskd.credentials=<redacted>
taskd.certificate=redacted.cert.pem
taskd.key=redacted.key.pem
taskd.ca=redacted.cert.pem
taskd.trust=ignore hostname
report.list.sort=tags-,entry+,start-,due+,project+/,urgency-

[kensmith]

I see this is by design, https://github.com/GothenburgBitFactory/taskwarrior/releases/tag/v3.0.0 . Still astonishing. Feel free to close as wontfix but I think you will lose users over this kind of thing. Best of luck to your project.

[polsvoice]

Same issue. Fortunately, I didn't have a huge task list. Regarding this:

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

How do you do this?

[polsvoice]

Okay, here's what I did. By looking in ~/.taskrc, I saw that my tasks were stored in ~/.task, so I cd'ed into that folder and did task import backlog.data, and that seems to have resurrected my task list. It now shows my tasks when I do task list. I was able to add a new task, delete a task, and complete a task.

However, whenever I do task list, it also says There are 123 local changes. Sync required. That number changes each time, and it jumped from 118 to 123 just by adding one task! I have no idea what is going on. It does seems to be working again, though.

[felixschurk]

https://taskwarrior.org/docs/upgrade-3/
Here is the documentation for upgrading to taskwarrior 3.0, basically exporting all tasks once and them reimporting them with the updated taskwarrior. It is also linked in the release notes.

https://github.com/GothenburgBitFactory/taskwarrior/blob/v3.0.0/doc/man/task-sync.5.in
Corresponding documentation for the update of the sync server.

bgregos/foreground#180
It might take a little bit of time, however I hope that foreground will also adapt to the latest storage backend, unfortunately I am not a Java developer and can not really help in that regard.

https://github.com/GothenburgBitFactory/taskwarrior/issues/3299
Addresses also the issue described here and is working on a solution.

[imran-iq]

Same issue. Fortunately, I didn't have a huge task list. Regarding this:

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

How do you do this?

Depends on how you installed taskwarrior. I use arch so pacman keeps a copy of every package in /var/cache/pacman/pkg

So you can do doas pacman -U /var/cache/pacman/pkg/task-2.6.2-2-x86_64.pkg.tar.zst do the export, then install 3.0 and do the import.

Other package managers may do the same, I am not familiar with them. Worst case scenario build the old version from source

[Spacewalker2]

I don't have any package to downgrade to please provide a migration sub command.

[guyjames]

jfc I've wasted so much time on trying to fix this, and now I find it's by design! 👎 It happened to coincide with another issue with file permissions so I thought that was the cause. This upgrade also totally breaks syncing with WingTask (so far the only non-self-hosted solution I've found for syncing TW - and presumably it would have broken self-hosted solutions too). My 'mistake' was to do a simple pacman upgrade. I don't know if there's a way that users can be warned before upgrading without going to the github of every single package in the upgrade (can be well into the hundreds), something along the lines of 'Warning: if you install this upgrade the app will stop working and you will lose access to your data!'. Going to try downgrading now.

[djmitche]

I'm sorry for your frustration. I just finished debugging a sync issue that resulted in an important task mysteriously disappearing while other tasks continued to sync between task instances. This is something we rely on, so the failures tend to occur at a time we need to be doing something else, making the failures all the more aggravating. In fact, this is what led me to start on what became 3.0 about 5 years ago.

I don't have any involvement in any of the downstream distributions that would package Taskwarrior, and I am quite surprised that Pacman blithely upgraded you over a major version bump. In my experience as a user of various distros, typically this is handled either by allowing major versions to be installed side-by-side (e.g., postgres 15 and postgres 16 can both be installed at the same time) or by shipping the major version upgrade in a distro upgrade (so maybe Ubuntu 24.04 has Taskwarrior 3, while the older Ubuntus keep shipping 2.6.2). In fact, homebrew specifically called out this bump although that hasn't been handled yet due to a build error.

[kensmith]

I spent many years managing engineers so let me first say that I totally get the desire to rewrite things from scratch, particularly in Rust. I also want to express my gratitude to the authors of Taskwarrior for their contributions to this project and in general. This is a big project and you all do this as volunteers. Much respect and love.

TW3 is not a major revision, it is a new product. It is a breaking change in storage format, sync backend, and many other things in between. One way this could have been more gracefully released is as a new project v1.0 (eg. taskchampion which seems to be a component of the new architecture) with clear guidance on the benefits of moving to the new project with scripts to manage converting existing configs to new configs including automating away some of the hassle of converting the server config which, tbqh is a lot of work with TW2.6. Rather than force all existing users to take a breaking change, invite them into the new project and then put the existing TW2.6 lineage into maintenance mode. This would also be an opportunity to explain the benefits of the new codebase. What do existing TW users get when they convert their task and server config to the new taskchampion (placeholder for lack of a better moniker) world? Taskwarrior is already a community project so it would be quite fair to leave 2.6 issues as wontfix unless community members provide PRs which address them, freeing the authors of the new platform to concentrate their enthusiasm on the new code tree.

This breakage is particularly onerous because good productivity tools should be so transparent and immediate that they disappear from a person's workflow. Taskwarrior was one such tool. I only started using TW a couple of months ago and one of the things I had enjoyed about it is that the commands are simple and run fast on any of my machines even the super old ones. It had successfully 'disappeared' for me up until 3.0. The fact that it reappeared so vividly and so demandingly of my time to go and take on a new project to spin up on the new workflow was quite unwelcome. I'm quite certain I could 1) maintain my own fork of 2.6 and then handle any issues that come up by patching the C++ myself, 2) port my tasks and server to the new workflow, etc., but I won't. I'm too busy and I differ too far from the philophy of this project given its willingness to impose this level of change on its users. I've put my task list into a vimwiki until I can find a replacement. If the project decides to revert this project to the 2.6 code fork and create a new separate project per my completely unsolicited advice above, I would be quite grateful and would go back to just working with TW for the next months or years until I found the time to take a look at the new project.

It will be a wildly fascinating social experiment to see how many people go through the work to convert all of their tasks into the new world order and persist using the new and improved Taskwarrior. As I said in an earlier comment, I think you'll lose users over this. It violates the principle of least surprise which I hope they still teach to young programmers. It was beaten into my head by my mentors, for whom I remain grateful.

[kensmith]

One other piece of data that I didn't include in my previous comment: like @imran-iq and maybe some of the others, I got tw3 via a pacman upgrade on Arch. One way this issue could potentially be addressed is to change the way tw is released on Arch specifically. For example, it could be split into taskwarrior2 and taskwarrior3 packages, allowing people to opt in to the 3.0 lineage when they want to rather than automatically. Python did this on arch for many years (maybe still) to allow people to run older programs and then slowly opt in to the new world, or even run both revisions in parallel for a while.

If you wanted to be really slick, you could even create a way for the old sync server to sync with the new sync server which could possibly reduce the friction along the migration path. Again, I acknowledge that y'all do this as volunteers so I'm not demanding anything there, just throwing out some ideas.

[ryneeverett]

I think this highlights the somewhat paradoxical wall between satisfied users and developers.

The happiest users will never give any feedback and are thus invisible to developers and unrepresented in decision-making. Anyone who becomes a developer of OSS productivity tools does so to fix their dissatisfaction with said tooling.

On the other hand, satisfied users are blind to the technical debt that their tooling rests on. If they were charged with addressing this debt they would likely be more open to change.

[ryneeverett]

To put it more concretely, the decision likely would have been different if someone with your position had been a participant. But your position might have been different if you had the perspective of a maintainer.

[kensmith]

I would have thought my response convinced you of my empathy for the plight of the maintainers. I get the desire to address big structural bugs with rewrites. I also get the desire to enter into the world of open source to solve a category of issue that isn't solved to one's satisfaction in any of the existing offerings.

Part of why I weighed in with my lengthy comment above is precisely because I absolutely understand how these things happen. I've seen it in many large and small ways in my roles as a leader in engineering teams. If I weren't so busy, I might even join this project to help do some of the things I propose. For what it's worth, I'm working on the Arch side to see if we can split the packages per my previous comment re: task2/task3. But thank you for your comment because I do think that we are speaking about issues of software development philosophy in general and not just this change specifically. You rightly point out some of the tradeoffs in this tension between dissatisfied end users and enthusiastic maintainers.

[ryneeverett]

I didn't mean to accuse you of lack of empathy. I'm more regretting that it seems inherently impossible for a more conservative position such as yours to be represented before breaking your setup.

[pglaser-engineer]

For what it's worth: most of my systems are running on Manjaro, and, being more actively managed with respect to upgrades, tw3 was not even available from any of its repos. So I had to get the tar file from the arch package repo and install manually. In my case, I was fortunate enough to have noticed the instructions for updating before I did so.

When I did a full update on the one machine that I have running Arch, I was really surprised, as expressed by others above, that it upgraded to tw3. I immediately thought about how many users could get a big surprise.

It makes sense to me that the Taskwarrior team can't really control how downstream packagers distribute updated packages.

That said, the one suggestion I might offer is that tw3 could detect when the sql lite file is absent from the data directory and issue an error message to the effect that the data need to be exported in tw2 and reimported under tw3. My guess is that many users are going to start running into this. While this approach does not address the entire problem, at the very least it would help users understand that they need to downgrade to tw2 and either stay there somehow or export and upgrade and import.

Thanks for listening.

[ryneeverett]

That said, the one suggestion I might offer is that tw3 could detect when the sql lite file is absent from the data directory and issue an error message to the effect that the data need to be exported in tw2 and reimported under tw3. My guess is that many users are going to start running into this. While this approach does not address the entire problem, at the very least it would help users understand that they need to downgrade to tw2 and either stay there somehow or export and upgrade and import.

See #3321.

[kensmith]

I didn't mean to accuse you of lack of empathy. I'm more regretting that it seems inherently impossible for a more conservative position such as yours to be represented before breaking your setup.

Thank you for your comment. I respectfully disagree that there is an inherent impossibility between breaking changes and least surprise. Like I said in my long comment above, I view the delta between 2.6 and 3.0 to be more than a major revision. There are many ways to take both the conservative approach and releasing the overhauled version. Two of which I've also outlined above, namely, consider this a new product or release parallel versions so people can opt in to the overhauled version on their own schedule rather than on the project's schedule.

[kensmith]

https://gitlab.archlinux.org/archlinux/packaging/packages/task/-/issues/1

[imran-iq]

Yeah this is more of a ball dropping on arch's part unfortunately. Usually they have a news update for breaking changes like: https://archlinux.org/news/budgie-desktop-1072-6-update-requires-manual-intervention/ but it looks like it was missed this time around. (Thank you to @kensmith for following through on that front).

Just as a more general note though. I do get the frustration around breaking changes, however lets all remember, as per the licence of this software:

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

I'm astonished that this breaking change was released without backward compatibility. I'm likely going to abandon Taskwarrior

Let's not build up entitlement on a free product that was built and shared on nothing but goodwill of the maintainers. It is a good way to burn out maintainers

https://mikemcquaid.com/entitlement-in-open-source/

[kensmith]

I did not intend to imply, nor do I think I did insinuate, that I or anyone should feel entitled to even the existence of taskwarrior much less entitled to the project taking a particular direction. My main point is that this change, violating the principle of least surprise, puts it at risk of losing users, myself included. I didn't say that this was a problem for the project, just a friendly comment from the wild on what could be incoming. Perhaps other more methodical distros will handle this in a way that sidesteps the breakage. And, yea, Arch can hopefully adapt to the change as the linked task gets resolved. I hope that clarifies my position.

[djmitche]

As I said earlier in this thread, I appreciate the frustration (and have experienced similar frustration with other TW breakage), and I'm sorry for that. I appreciate the empathetic comments!

To the point of this being a new project, there's some additional background on how the decision not to fork was made here. Availability of maintainers' time was a factor in that decision. No decision is perfect, and others may have made a different decision, especially in different circumstances. But please know that we did take some time to think about this one.

Two data points to the "rewrite it in rust" comment. The goal here was to build a reliable, secure implementation of the task DB, to replace the existing ad-hoc, buggy and insecure implementation. Rust was a good choice for this work, but was not the motivating factor. Second, there are no plans to rewrite the remainder of Taskwarrior in Rust.

If someone would like to maintain the 2.x series going forward, please get in touch. I don't, personally, have the capacity to do so.

On a procedural note, I'm going to convert this from an issue to a discussion as I think that better represents what's going on here.

[kensmith]

I appreciate the comment. Please don't take my 'rewrite it in rust' comment disparagingly. I supported multiple engineers on independent teams who looked at everything in their way as a reason to #RewriteItInRust so often that it became a meme, replete with gifs and everything.

Thank you for the context on why this decision was made. I see from the linked discussion that you intially went in the direction I suggested earlier with a fork which is interesting to see. That comment thread is a little light on detail but I guess I still regard this choice in direction to be unfortunate. In particular, you cite that Taskwarrior has a large ecosystem of tools. This is true and is one of the reasons I chose to start using it. In particular Foreground for Android is pretty good but it is also broken for now. So, even if Arch solves the issue for people who were surprised by the upgrade, there are still tools in the wild which rely on the old behavior and will also be broken until they are upgraded. When they are finally upgraded, they will break for users left behind on legacy versions.

These decisions are hard and I appreciate that you made them carefully. Again, much respect and appreciation for your work on this. I know that these things take a lot of time and care and that you are doing what you think is best for the project in the long run.

[felixschurk]

Maybe as a side note, I noticed the upcoming release of Taskwarrior and as I also use Foreground I also thought about the changes that it would imply. Sadly, my knowledge in Kotlin/Java is too low to incorporate the changes.

@djmitche gave already an idea on how one could update Foreground to have it compatible with Taskwarrior in bgregos/foreground#180.

[gour]

As I said earlier in this thread, I appreciate the frustration (and have experienced similar frustration with other TW breakage), and I'm sorry for that. I appreciate the empathetic comments!

I just want to throw my €0.02 here...

No doubt, it is frustrating when updating of some package does break its normal/expected behaviour...

However, if taskwarrior is an important package in someone's productivity workflow, then I assume it is normal to check, from time to time , what is going on with its development.

3.0 released was planned may years ago and I was constantly monitoring what is going on. Frankly, I was alwyas expecting that 3.0 is going to solve TW's recurring problems since the release was planned as "recurrence overhaul". But, the development was stalled and I'm very happy that @djmitche stepped up and infused fresh energy into almost dead project.

"Recurrence overhaul" is still not there, but I'm sure that 3.0 is providing a solid foundation for further development.

Moreover, current 3.0 release did not happen out of thin air and it was reported that it requires careful migration which is documented. Same thing in regard to taskserver...

So:

1. the new release was planned long ago with sufficient information how the update is supposed to be handled
2. major distributions (Debian, Fedora, openSUSE...) are still on 2.6.2 - if Gentoo's package is not updated (yet) 😉
3. there is one useful procedure one is supposed to perform regularly on the machine(s) holding important data, and it is called "backup"

Considering all those points, one could easily avoid "Upgrading to 3.0 broke everything" scenario or easily revert from the last backup holding 2.6.2 data.

I'm well aware of the 3.0 release and all the consequences of 2.6.2 --> 3.0 upgrade, but I still wait for my distro (openSUSE Tumbleweed) to update the package...

If you didn't pay attention to any of the above-mentioned three points, you simply are not entitled to blame TW developers for selflessly using their spare time to work on the application and giving it to us freely.

Sincerely,
Gour

[kensmith]

I get all that. To be fair to your criticism, the title of my opening issue is not ultimately descriptive of the issue. I'd be happy to change it if that would help but if you read all of my comments, you'll see that I don't think that "3.0 broke everything" ultimately. I make this same point in my very first comment after opening the issue after realizing that this is by design.

Of course, if someone is going to use something, it pays to know the history. On my machine pacman -Q | wc -l is 774. Keeping up with the plans and preparations of 800ish packages is probably not something that a person should be reasonably expected to do. Never in my comments do I "blame TW developers" of anything. I think the migration plan could have been handled better but they are absolutely within their right to spend their free time on this project the way they see fit. This was a nonbug and so converting it to this discussion was right and appropriate.

Change management is hard. It's super easy to get it wrong and getting it right across the large tooling surface that this project covers is a lot of work. Kudos to the team for the effort they put into trying to do so. Managing change is a partnership between providers and consumers of any product. Consumers are best when they're flexible and producers are best when they honor the needs of the consumers. No one who uses open source is entitled to the time of open source contributors.

The most successful software projects were extremely passionate about backward compatibility. Like them or not, Microsoft was exemplary in this regard through the 90s and the early aughts. Old DOS programs still ran on fairly recent versions of Windows. Maybe they still do. This is part of how they have managed to grow and keep their customer base. There's probably a lesson in there somewhere.

[djmitche]

Thanks! I'm OK with the title of this discussion as it's providing a central place for people to share their grievances. So far, those have all been civil, with occasional signs of understandable frustration.

Regarding the recurrence overhaul -- I want that too! But I suspect I'll be busy with the followups to the sync ad data model for some time now, so I think the situation is the same as it has been: that work is waiting for people to do it. As you've said, @gour, I think the new support sets a good groundwork for a new recurrence model.

[djmitche]

I'll just take advantage of the attention on this topic and say, if anyone has some time available and can help with any of the most pressing 3.0 bugs, I'd really appreciate it. You can find the list here.

[mrossinek]

FWIW, those who use Arch Linux can now find the task2 package in the AUR. It compiles from source (only once of course) but it means you can install the package, replacing the task package which provides task>=3. Everything should still just work in the same way and then you can continue updating your systems without worrying of accidentally upgrading task while you have not completed the transition/upgrade process.

If bugfixes will be provided for 2.X of taskwarrior (which I don't know if they will) I will update the package accoridngly.

[djmitche]

Thank you!

I'm open to continued maintenance of the 2.x branch, but will not be putting my own time into it. I'd be happy to coordinate with anyone who wants to take that on.

[angelus2014]

First off, congratulations to the developers of TaskWarrior with the 3 release, but which also means the end of the journey with TW for me. I was one of the people who was surprised that in my package manager (Homebrew) to see a new version of TW only to be confronted with not being able to open my tasks any more. Sadly, Homebrew doesn't offer much of downgrading. And no, Homebrew did not show any sign or mention of it being a breaking change.

I rather think I could compile the source of the latest 2.x version, but to be honest I don't think I will put in the time. 3.0.0 doesn't offer what I still think to be the biggest issue with TW: recurrence.

For me the sync was never a problem as there are many other ways to sync plain text files, I use SyncThing and Git (which also gives me nice version control). Also, the move to a database breaks all my (small) scripts that I've built over the years as they depend on it being text files. I seem to remember though that in the past there was mention of it being up to the user whether to switch to a database?! But perhaps I'm mistaken…

I wish the developers good luck with further developments, but alas for me, there doesn't seem to be much future in continuing with TW.

---

With regards,

Angelo Machils

[gour]

I rather think I could compile the source of the latest 2.x version, but to be honest I don't think I will put in the time. 3.0.0 doesn't offer what I still think to be the biggest issue with TW: recurrence.

That was/is still my sour point regarding TW and I was also hoping to see “recurrence overhaul” in 3.0... My distro (openSUSE Tumbleweed) is still on 2.6.2, so didn't have an opportunity to test 3.0.

Due to recurrence, I've tried several other applications, but TW is the most productive for me, but recurrence-wise I can recommend trying Etm which is practically capable to specifying whatever you like.

[djmitche]

There's an old RFC for this - perhaps one of you was involved in drafting it! https://github.com/GothenburgBitFactory/taskwarrior/blob/develop/doc/devel/rfcs/recurrence.md

Depending on availability of resources to work on this functionality, maybe it makes sense to pick up this effort and carry it forward?

[aheneneu]

My TW broke after I upgraded it to v3 with homebrew on MacOS. I managed to export data by first installing v2.6.2 on VPS running Ubuntu with apt install taskwarrior, copying files from ~/.task on local machine to the server, and running task export > all-tasks.json. Then I downloaded all-tasks.json to local machine and imported it with task import rc.hooks=0 all-tasks.json. I hope anyone will find it useful.

[gour]

There's an old RFC for this - perhaps one of you was involved in drafting it! https://github.com/GothenburgBitFactory/taskwarrior/blob/develop/doc/devel/rfcs/recurrence.md

I just did submit some tickets or other form of communication what is expected by "proper recurring support".

Depending on availability of resources to work on this functionality, maybe it makes sense to pick up this effort and carry it forward?

Unfortunately, my C++ skills are pretty rusty (pun intended) and neither enough time to dive into Rust. My (research) plate is simply too full to be able to contribute in code. 😢

[djmitche]

Got it. Maybe there are others who can work on this!

[Robotic-Brain]

Hi, i just had a small scare seeing all my tasks vanished after (unknowingly) upgrading from 2.6.2 to 3.0.0.

I see that this is expected and documented behavior but considering the nice task news interface made absolutely NO mention of the changed database format (a BREAKING change!) AND the cumbersome: "downgrade to 2.6.2, export, upgrade to 3.0.0, import" process, this is a major screw up when it comes to release management!

The 3.x versions should at least be able to read and convert from the old format transparently.
Even if this is too much to ask, just include some small check like "Hey we see that there are old task files in your data location, you might want to convert them. Here is a tool to do that: LINK"
3 Lines of code could have prevented, at least part of, the backlash from above.
(EDIT: I just found out this has already been fixed in v3.0.2! ❤️ )

All is fine now since i just locked the TW version in my package manager down - for now. This situation is just deeply disappointing because i always used TW and its task news feature with its "What do i have to do" section, as a prime example for good release management. ☹️

---Rant over
Thanks for all the Fish!

[wrashi]

Rant noticed. :)

As with everything in life, TW faces trade-offs that require sub-optimal decisions to be made sometimes, usually because of lack of hands to do the work. This upgrade situation was one of those. If you'd like to help improve how things happen, we'd love to have you join the next bi-weekly meeting in 2 weeks. Watch this discussion space for details.

[DeadlySquad13]

Good to hear that this project is finally migrating to sqlite! Have always thought it's way better for future extensions and integrations. The only thing that makes me sad is sync changes: I have found a promising ansible role for setting up a taskwarrior just a few days ago!.. Hope, we as community will develop new ways to easily deploy personal task server.
By the way, in manual it's said that there's no merge feature on personal servers. Can we merge conflicts by hand somehow? Will automatic ways ever be addressed?

[wrashi]

Great questions, @DeadlySquad13! Task server deployments are definitely something on the radar. If you've got a bit of time on Saturday, Come join the community meeting to get some insight into progress and where things are headed.

Bi-Weekly meeting announcement

[ryneeverett]

By the way, in manual it's said that there's no merge feature on personal servers. Can we merge conflicts by hand somehow? Will automatic ways ever be addressed?

I think you're referring to the "File Sharing Services" section, right? File sharing services don't know how to do merges -- and how could they? -- but implementations of the taskchampion sync protocol such as taskchampion-sync-server handle merges automatically.

[djmitche]

In particular, the new sync protocol is designed to behave predictably for any combination of changes made across replicas. Historically there were a few ways that tasks could get in a "funny state" such as having status:waiting but no wait date. We've worked to eliminate those, and in principle any combination of task attributes can now be interpreted meaningfully as a task.

[DeadlySquad13]

I think you're referring to the "File Sharing Services" section, right?

Yes

File sharing services don't know how to do merges -- and how could they? -- but implementations of the taskchampion sync protocol such as taskchampion-sync-server handle merges automatically.

It seems I misinterpreted manual. Didn't know that taskchampion sync protocol implementations are being developed in parallel and with even better capabilities than earlier! I will follow changes in this field. Hopefully, it will evolve from a POC state.

Thanks to all of you for quick replies!