[petsc-dev] significance of version numbers

[Jed Brown]

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