This post originally appeared on my Patreon.
Twine 2.0.9 is going to be a maintenance-oriented release. We have three new languages that have already landed on the main development sourcebase: French, Dutch, and Brazilian Portuguese. There's also a pull request for Russian that I'm excited about getting landed. I think there's a sizeable interactive fiction community that speaks Russian, so it'll be cool to give them something that works in their native language.
The other big change I want to land is totally under the covers. After talking with some fellow developers at the CharmCityJS meetup and getting advice on the workflow I've set up for myself, I've been working on refactoring the code structure a bit so that we use Browserify to split the code up into more manageable modules. If I do this right, regular users won't see any difference, but it will be way easier to work on the code. This not only makes my life easier, but will also make it easier for other developers to contribute to the other project. As of August, the work on this end is pretty much done, but I am waiting on the next part to land those changes...
... which is that I'm overhauling the automated tests for Twine. Up until now, I'd been using Selenium IDE to exercise Twine before release. It's a Firefox plugin that automates browser actions and verifies they have the result you'd expect. Working with Selenium IDE has always been OK at best. I could never get a few tests to work predictably, so every time I did a release, I had to manually step through a few to make sure things would work correctly. This kind of friction always annoyed me, but I put up with it because it was the best way I knew how to do it.
So, also at the suggestion of fellow CharmCityJS'ers, I've been working on moving the Selenium tests out of the IDE and into the build process I've been using, Gulp. This has the advantage of being more convenient to run -- a single command instead of having to navigate a GUI -- but also promises more reliability. We shall see. The JavaScript bindings for Selenium are pretty full-featured, but it's taking me some time to translate the IDE tests into JS because the best documentation I've been able to find is the API docs. It is a bit like trying to learn a language by skimming through a dictionary. Suggestions welcome!
My theory is that I'll use the revised browser tests to validate the code re-organization. A major refactor is always a little perilous. Perhaps your code was ugly, but it had been working right for several releases. The automated tests are a way to better guarantee that.
That said, I'm still planning to do a prerelease test version to the world at large to catch anything that slips through the cracks. This release has been a bit slower to get out the door than others this year, mainly because I'm doing a lot of learning along the way. That said, I'm shooting for mid-September.