[petsc-dev] significance of version numbers

Satish Balay balay at mcs.anl.gov
Sat Mar 6 13:09:57 CST 2010

On Sat, 6 Mar 2010, Jed Brown wrote:

> 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.

Each time this issue comes up - we go though a list of rationale and
slightly modify the naming convention.

And we never land at the orignial-intended convention you are refering
to. Perhaps one rationale used was: Currently linux-kernel only
changes the sub-minor version for any and all changes - so current
petsc scheme is equivalent, [instead of .p1,.p2, linux kernel uses an
extra .1,.2 etc..]  and no need for petsc to adhere to the original
convention. [Also as you indicate - gnome also doesn't conform - by
removing subminor release number]

Are you sugesting going from:




The alternative - not suggested is:

[if changing - I guess I don't mind the third one - provided the
curent workflow is preserved.].

Any change is bound to create some confusion with users..


More information about the petsc-dev mailing list