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
