The development cycle has turned another full 360° again. We started from 0.7.0. Developers have put in a significant amount of hours, fixed many bugs, added some features (and inevitably some new bugs). Translators have updated the texts. Builders have updated SDK and released snapshots for testers to test and give feedback to developers until everybody was happy with the result. And then we release to the general public.
It is an established convention in the world of software that version numbers have a major and a minor version number. Sometimes even more, like in our case three numbers separated by a dot. It is also an established convention that an uptick in the major version number means major change and an uptick in the minor version number is a small change. Last but not least, a 0 in the major version number is often interpreted as: the software is new and still uncomplete.
So how should the general public interpret a move from 0.7.0 to 0.8.0? Not according to conventional wisdom, it seem.
Hugin 0.8.0 is a complete different thing than 0.7.0. It adds features and projects started more than a year earlier and that are revolutionary compared with 0.7.0. Because of the massive progress it requires newer versions of upstream dependencies. It adds new functionality while maintaining backward compatibility for user’s comfort. While there is still a lot that can be developed, added, improved, it is neither new nor incomplete.
Hugin does not deserve a 0 as a major version number.
I discussed this topic with Pablo after LGM and he came up with a good idea: from now on the major Hugin version number shall be the year in which it is released. And just in case we get to accelerate our release cycle (proposal coming), the minor version number can be the month in which it was released. We can keep the third version number for fixes and so on.
So I made the official proposal to the community. Welcome Hugin 2009.07.1 a.k.a. 0.8.0 – the best Hugin ever!