The goals of software versioning, as I understand them:
- Give each build (release, snapshot) a unique identifier.
- Apparent order: it must be obvious which is newer when comparing 2.
- Apparent changes: contains breaking changes, new functionality, or just bug fixes.
- Possibility to release updates later on that "fit in between".
Apparent Order
1.9.0 -> 1.10.0 -> 1.11.0This is important for me as a user, it lets me select the newest version quickly.
Apparent Changes
Going from 1.9.0 to 2.0.0 may mean that some of my use cases need to be adjusted, some things don't work the same anymore. I might prefer to stay on the "1" branch.Going from 1.9.0, 1.10.0 contains more functionality, it seems pretty safe. Experience taught me that new features bring new bugs - even if I don't make use of the new stuff.
Going from 1.9.0 to 1.9.1 means there are just bug fixes. It is almost a safe bet to upgrade this. A quick look over the change-list helps me to decide where I might be affected. The risk is very low that this introduces new bugs.
Release Updates
When after 1.9 the version 1.10 has been released, and then bugs are found in 1.9.0 that should be fixed, not everyone will be happy with a 1.11 that now contains new functionality and bug fixes. Hence the 3 numbers.H2 Database thinks otherwise
Unfortunately this software library that I use, like and value follows a different version system. Just like Google Chrome, they have been publishing new versions with what is effectively a single continuous version number.For a recent history see http://www.h2database.com/html/changelog.html
And longer: http://mvnrepository.com/artifact/com.h2database/h2
There are no bug fix releases. Each new version brings new features, improvements, bug fixes, and new bugs, which becomes clear when you follow the issues. But to learn in which version they were introduced, and so on, you need to dig and read the bug tracker.
For a web browser, this release cycle OK. Give me the latest, I can cope with some level of annoyances and crashes now and then.
The database however is the back bone of many applications. It is the piece of software that one relies on, that is the worst to break. And as such, I really wish it would maintain two code branches. One for latest developments, and one that lags behind where just fixes are applied.
Whenever I consider updating this library in my code, I hesitate. Is it really necessary? Most times I answer no and move on. Updating means reading all recent changes, and running tests.
I only use this database for read-only scenarios, not as a live database with active changes.
My suggestion to H2 and in general
- Move code from Google Code to GitHub
- Change to semantic versioning
- Create a branch that lags behind, and let contributors do the work of maintaining it (applying just the fixes)