[petsc-dev] significance of version numbers

Jed Brown jed at 59A2.org
Sat Mar 6 14:21:47 CST 2010

On Sat, 6 Mar 2010 13:59:58 -0600 (CST), Satish Balay <balay at mcs.anl.gov> wrote:
> What I meant to say is: [if you ignore 2.3.2->3.0.0 jump] PETSc also
> complies with the same logic. You can say - petsc uses the eqivalent
> 3.0.x.py notation.

2.2.1 to 2.3.0 (instead of 2.2.2) also seemed somewhat arbitrary to me.
I suppose 2.2.0 was more major in that the entire SLES object
disappeared (I started with 2.2.0).  Doing subminor releases, with minor
releases reserved only for cases of similar impact (a major user-visible
object vanishing), and doing major releases only for something on the
scale of a full rewrite would also be a self-consistent model.  I just
don't see the value in having major, minor, and subminor releases all
mean the same thing up to a subjective opinion of "how much" it is.

> We've given up on preserving ABI changes in releases a long-long

Yeah, it's a huge amount of effort, and really crippling when the goal
is to actually make things better.

> Well petsc patches are now becoming more than just bug fixes. [they
> are generally minor fixes - could be additional functionality].

Then I would be happy with getting rid of "patch levels" and just using
subminor for these compatible changes.


More information about the petsc-dev mailing list