[petsc-dev] significance of version numbers

[Satish Balay]

On Sat, 6 Mar 2010, Jed Brown wrote:

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

Sure - we have not been consistant - and going forward - each time
these discussions come up - we keep changing direction. the 2.1-> 2.2
-> 2.3 rev-changes were our attempts to try to quantify what a 'major'
API change could be. Perhaps the above changes don't meet that litmus
test.

2.1->2.2: SLES -> KSP [perhaps a string replacement - but no other major API change?]
2.2->2.3: elimination of BOPT[=g,O,g_c++,O_c++] - a major usability change - but API?


Since then - I think the discussion was to not bother with these major
revision changes [but then we had to do petsc-3.0.0 - a collection of
functionality upgrades, and f90 interface rework..]

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

Just stepping back - [ignoring the 2.1-> 2.2 -> 2.3 ->3.0 jumps] the
releases reflect our develoment workflow - which has improved in the
past many years.

The current workflow is:

- petsc-dev repo for any and all major changes

- every *many months* we do some extra testing and release petsc-dev
as the next release.

- when a release is done - have a branch repo for it. i.e
petsc-release-3.0.0 repo - where bug fixes and other minor fixes users
complain about - can go in. Ocassionally bugfixes go into petsc-dev
[but they should actually go into petsc-release] so these patches get
backported to petsc-release.

- Every so often [perhaps once a month] we create a tarball from
petsc-release-3.0.0 - and crank up the patchlevel. [i.e
petsc-3.0.0-p1.tar.gz]

- Now the patch repo is reset to the new release. [and no more patches
for the previous release]

With the above development model, I guess either of [current] or
suggested version numbering scheme is fine. So I have no objections to
change.

Regarding the implications of this change - the issues are:
- confusion to users [breaking the trend again]

- perhaps some of the macros used to check verson in some codes [that
work across multiple version of petsc] - might encounter issues.  [as
now the meaning of PETSC_VERSION_() and/or PETSC_VERSION_SUBMINOR will
change...]

Satish