Everybody rejoice! Here’s the newest tween.js release: r8 (change log).
There had been some improvements in the dev branch for a while but they didn’t seem enough for a new release. Some days ago we had an interesting issue come up in the issue tracker and that was the sparkle that made me finally sit down and write unit tests for the library.
OK, now that all of the purists have picked their jaws from the floor, can we continue the post? Right!
Yeah, the library has been out in the wild for two years and without tests. Terrible! Awful! I know, I know. But–we had the examples!
And the examples are fine, until lots of people come in and contribute new code to the library, and it comes to a point where the library magically does more than you remember it could do. So tests had to be written, but I wasn’t too sure about which framework to use. I had written this minuscule testing framework back in May but it felt a bit too simple… Then I discovered that Ben Houston, a very talented contributor to three.js, had been writing unit tests, so I had a curious look at it. He was using qunit, and it seemed simple but at the same time powerful enough to use. Therefore I picked it and started writing tests.
Unit testing is always an excellent way to look at the code with new eyes, and I quickly found oddities, even some bugs, so it was a good exercise. And once I finished, the code in the dev branch was way better than the code in the master branch, so a new release was sorely needed!
Still, the tests are somehow incomplete, and they surely can be improved, so feel free to contribute with your testing experience.
And how to contribute? Well, we’ve improved in that field too! I have written a Contributing page in the wiki which is heavily inspired by three.js’s Contributing page, and also added a CONTRIBUTING.md file that GitHub links to when you’re about to create a new issue, with the “Please review the guidelines for contributing to this repository” message on top.
All this contributing stuff is required because we’ve moved to a more ‘pro’ git workflow, where we use two branches now: dev, where active development happens, and master, where stable code goes. But the way GitHub works, the master branch is always shown by default and it’s not easy to notice there are additional branches at a glance. Hence, several people have asked about and opened issues related to things that had been fixed in dev already. When more than one person does something ‘wrong’, it’s a symptom that there’s something wrong in your manners, so to speak. So it was evident that a clarification was required from our side. Hope this helps everybody.
Thanks everybody for your contributions!