[petsc-dev] significance of version numbers

Barry Smith bsmith at mcs.anl.gov
Sat Mar 6 17:12:33 CST 2010

    I have no objection to making each PETSc release crank up the  
second digit. And organizing the numbers as 3.1-pX then 3.2-pX etc.

    Historical explanation why we had the strange numbering before.
1) Most PETSc users don't know anything about "Open source standards  
for release numbers" so we didn't feel a need to use it. It is only  
the occasional oddball like you that ever comments on this.
2) We use to make releases far more often, then I didn't like the idea  
of always cranking up the second digit since I felt it implied some  
relatively large changes in the libraries when there really were not  
any. So, yes it was somewhat arbitrary but not random.


On Mar 6, 2010, at 2:49 PM, Satish Balay wrote:

> 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

More information about the petsc-dev mailing list