TinyTask Version History and Release Record

You do not have to take a version list on trust, including this one.

Open Prefs and choose About TinyTask. The window names the version and prints the build date, which is the date the program was actually compiled.

That date is the single most useful fact about this software, and almost nobody reports it. It is years old. Whatever a download page tells you about updates, the program itself says when it was last built.

Two ways, and the second one is more reliable.

Ask the program. The About window above.

Ask Windows. Right-click the file, choose Properties, and open the Details tab.

The Details tab shows the file version, the product name and the copyright, all read from inside the file rather than from its name. A file can be renamed to anything. What is inside it cannot.

If the two disagree, or if either disagrees with the version you thought you downloaded, treat the file as unknown and verify it against the checksums in the table above. The safety page walks through the check.

Worth documenting, because it explains why a separate TinyTask version history is needed at all.

The developer's own site publishes a revision history, and it stops short of the release the same site offers for download. The homepage advertises a version and links to a changelog that does not contain it.

So there is no published account of what changed in the most recent builds. Not a lost page. Not a broken link. It was never written.

We are not going to fill that gap by guessing. Where we have no attributable release notes, the table records what we can verify, which is the version, the size and the checksum, and nothing more. An empty notes column is honest. An invented one is not.

Three real reasons, and one that is not.

Older Windows. Machines that cannot run a current build, or environments frozen on purpose.

A change that broke something. A later release altered behaviour a workflow depended on, and rolling back is faster than rebuilding the workflow.

Matching a documented setup. Someone else's instructions were written against a specific build and you want the same one.

The reason that is not real: newer is not automatically better here. This software has not been in development for years, so the newest build is simply the last one made, not an actively improved one.

Three categories are excluded on purpose.

Files from the editor downloads. Those are a different vendor's product entirely and belong in no version history of this program. The with editor page shows what they are.

Any setup installer. The developer's own documentation links one and that link no longer resolves. If a genuine installer is ever located, it gets verified before it appears here.

Anything we could not hash. If we cannot download a file and compute its checksum, it does not go in the table. A version list of files nobody can verify is a rumour with a layout.

Each file's size and checksum are verified against what is on record.

If everything matches, the page is unchanged. If a checksum has moved, the job does not publish the change. It flags it, and a person looks at it.

That last part is the important one. On software that has not been rebuilt in years, a checksum that changes does not mean an update has arrived. It means the file behind the link is not the file that was there before. That is something to investigate, not something to publish automatically.

Every row provides a direct download and shows the checksum for that specific file.

Verify before you run, whichever version you take. The command is on the safety page and it takes under a minute. If you only need the current release, the download page is the shorter route, and it covers the different file formats and what each is for.