We just published a new release on SourceForge, called 0.2-M2. In this release, we focused on improving functionalities that already existed in the previous milestone (such as formatting properties, lists, tables...) and adding new ones: indexes, comments, foot and end notes, frames, sections and page layout (including footers and headers). We are aware of some bugs - even files that make the converter crash - but globally the output starts to be acceptable for a daily usage.

Unfortunately, our roadmap was not synchronized with Word 2007's: a new realease, called Beta 2 TR, has just been published and is not compatible with our plug-in... The main problem is that if you want to test the ODF Converter, you have to install Word 2007 Beta 2 (not TR), which is simply not available any more! However, we could not postpone our own release, because it was already 10 days after the date we planned initially. So we simply decided to program a new milestone, 0.2-M3, before the final 0.2 release. M3 will only focus on making the converter work with Beta 2 TR (along with some bug fixes) and should be available as soon as end of next week. It should not be too complicated, as the changes between Beta 2 and Beta 2 TR are not that important. But we will profit from this occasion to clean up our code a bit. Yves and Karolina, our two technical leaders on the project (Yves in France, and Karolina in Poland) will work hard on the code during the next couple of days to ensure it is consistent and of high quality. As it is quite difficult to continue to work on a piece of code during a global refactoring, we decided to start to work with the remaining developers on the reverse transformation (from DOCX to ODT) during this period. So maybe 0.2-final will include some reverse transformation either (in the initial raodmap, the reverse transformation was only planned for the 0.3 milestone, starting end of october).

By the way, we set up a new regression test framework that will help us to track regressions. Due to the relative complexity of the code, and the number of persons working on it simultaneously, we have regressions quite often - files that Word won't open, formatting bugs, etc. Our new framework will allow us to ensure, before every commit, that a set of predefined files will continue to open in Word. For the ones who wonder why we did not set up a real unit testing environment, I would answer that with XSL transformations is it almost impossible. Unit testing involves very small pieces of code being tested separately. But as we are are continuously improving our transformations, it would have meant thousands of XML sample files - and sometimes we simply cannot isolate a functionality, so that our test files would have to evolve in the mean time: that is not really compatible with unit testing. I think it would not have been totally impossible - but far too complicated and time consuming for this project. So until now, we only tested the converter against some representative test files - but that was not always enough. From now we'll have this systemized through our regression test framework, consisting of a large set of files and an double validation process (against schemas and by trying to open the resulting files in Word) - all automated. We expect this new framework to speed up the development process, allowing to detect regressions very quickly.