Why WriteIDE 0.7 took longer than expected

This is a WriteIDE Lab note, not a release announcement. Stable 0.7 has not shipped; 0.6 is still the current download. The editor has looked ready for a while, but the final checks found a few places where Windows handles saved files differently. Those checks get the last word.

WriteIDE uses Electron, which lets us share most of the app across Mac, Windows, and Linux. The screens can look the same while the operating systems follow different rules underneath—especially when files are being saved, closed, or cleaned up.

For a writing app that keeps your work on your computer, those details matter. Your manuscript is not a disposable download. If WriteIDE says a save, backup, or import finished, the standard cannot be merely “nothing crashed.”

One app, three sets of file rules

Windows paths begin with drive letters such as C:\. Mac and Linux paths do not. The systems can also give different answers when WriteIDE saves, closes, or removes a file.

That is where the late 0.7 problems lived:

• After replacing a file, WriteIDE asks the computer for one extra confirmation that the folder change was recorded. Windows answers that particular question differently. WriteIDE now accepts only that known answer; genuine failures to open, write, or close the file still stop the save.
• Code written around a path such as /some/folder can make the wrong decision when the real path is C:\some\folder. Those checks now understand Windows paths directly.
• Windows will refuse to remove a test folder while any part of the test still has its database open. The test now closes every owner first, then briefly retries only that temporary “still in use” result.
• Windows-style line endings can also make identical text look different to an exact comparison. Those files are now kept consistent.

None of these problems were different buttons or a different editor. They appeared where one shared app met three operating systems that still do some important things differently.

A test that runs out of time did not pass

One Windows test run reached its 35-minute limit without reporting a failed test. It was tempting to call that good enough. It was not.

A timeout only proves that nothing failed before the clock ran out. It does not prove that the remaining tests ran or that the final cleanup finished. It is like stopping an exam with ten pages unanswered: there may be no wrong answers on the completed pages, but the exam is still incomplete.

The answer was to change the test setup, not lower the meaning of “passed.”

The Windows checks now run in seven independent parts. The largest database section is divided into four complete groups, and each result belongs to the exact code it checked. If one part fails or loses its connection, only that part needs to run again.

That saves time and money while keeping “passed” honest: every required part must finish.

When a missing folder is not a simple answer

One last problem came from cleanup code shared with an unfinished PDF-review feature. The feature is turned off in 0.7, but deleting a project still passes through the same safety checks, so that cleanup must be correct. It follows the same stop rather than guess rule as WriteIDE's other unfinished export work.

The bug sounds almost absurdly small: what does a missing folder mean?

It can mean an earlier cleanup completed successfully. In that case, a second cleanup request should simply do nothing.

It can also mean cleanup is still waiting and the folder was moved somewhere else. In that case, treating “missing” as “deleted” would throw away the last reminder that work remains.

Think of it as a cleaning checklist. If the folder is gone and its checklist is already signed off, the work finished earlier. If the folder is gone but the checklist is still open, WriteIDE cannot know whether it was deleted or merely moved. It keeps the checklist and reports the problem instead of guessing.

A fix meant to make repeated cleanup harmless briefly treated both situations as the same. Its small set of tests passed. The larger database test run caught the two missing-folder cases the smaller set had missed. The corrected rule is simple: if the checklist is still open, keep it and report the uncertainty; if it is signed off, there is nothing left to do.

That may sound like a lot of care for deleting a temporary working folder. It is also the point. Software trusted with your local files should be cautious when it cannot prove what happened to them.

What this changed

The lesson is not “Windows is bad.” The useful result is a stronger release process:

• A green result belongs to the exact code that was tested, not something almost identical.
• A cancelled or timed-out run means “we do not know,” never “close enough.”
• The real database code is tested on Windows before a stable release is published.
• Large test collections are split into complete groups that can finish and report separately.
• Cleanup trusts its written checklist instead of guessing from a missing folder.
• After the installers are published, an actual Windows 0.6 installation will be updated to 0.7 and checked with real project data.

I am keeping that promise in future tense until the check is complete.

Why hold the release when the editor already works?

Because the editor is only what you can see. Behind it, WriteIDE must protect the saved copy of your book, recover after an interruption, avoid deleting anything it cannot identify, and publish updates only after every required check finishes.

Electron lets one small project build the same writing experience for three operating systems. It does not make those systems agree on what “written,” “closed,” “missing,” and “finished” mean.

Stable 0.7 will ship when those words have evidence behind them. Until then, this remains a Lab note, and the download remains 0.6.