[petsc-dev] significance of version numbers

[Barry Smith]

    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.



    Barry

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