In my experience, a "root" supertask like this is not useful. It is by definition the parent of all tasks (master of none?) and therefore has no utility. It will only be completed when the project is done, at which point closing it is the equivalent of turning off the light switch after you've finished moving out.

That makes a certain amount of sense. It has two pieces to it, do you think we can just split those out as two tasks? It's not like we can skip them. Presumably if it were a more usual software release with a lot of components, they would all have to be listed in a release checklist somewhere so the release would work. This is just a very simple release, but shouldn't we still name the steps, even if there are only two? Maybe I've forgotten some steps, but if there is no place to hang them, then maybe they won't get recorded.

I think two separate "co-tasks" that are jointly the parent of all tasks is preferable, yes. What I was getting at is that we don't need to check if the "Do the whole thing" task is complete to know that the thing is done. If all the tasks with this tag are marked done, or "not needed", we know the thing is done. Going further, as long as every task in this project has the project tag, it's not necessary to define a strict or rigid task hierarchy/tree of parent/subtask (and could even get cumbersome if people think they can't work on a task because the subtasks aren't all done). I don't mean to be overly crtical, especially if you find the scheme useful, and I'm not trying to start a yak shaving contest, so of course be bold.