There is a convention followed by the majority of free software projects that subminor version increments should have a backward-compatible ABI. So additional functions, changes to private structs, etc., are fine, but changing/removing function prototypes, etc., should only come with a minor version increment. Following this convention makes life easier for packagers and administrators, and I don't see a compelling reason not to conform.
PETSc's quasi-annual releases always make some ABI-incompatible changes, and I don't see any clear distinction between what qualifies for a minor versus subminor release. Sure, some releases have "more in them", but that is difficult to quantify and in my opinion, not an especially useful metric by which to distinguish releases. So why not always do minor releases unless a release really is ABI-compatible? It's not like we're going to run out of numbers, Gnome is on 2.28 (they don't seem to bother with a subminor number at all, presumably because they just don't make that sort of release). Note that I'm not suggesting that subminor numbers be used in place of patch levels since those are purely bug fixes and contain no new functionality. Jed
