On Sat, 6 Mar 2010, Jed Brown wrote: > There is a convention followed by the majority of free software projects > that subminor version increments should have a backward-compatible ABI. > So additional functions, changes to private structs, etc., are fine, but > changing/removing function prototypes, etc., should only come with a > minor version increment. Following this convention makes life easier > for packagers and administrators, and I don't see a compelling reason > not to conform. > > PETSc's quasi-annual releases always make some ABI-incompatible changes, > and I don't see any clear distinction between what qualifies for a minor > versus subminor release. Sure, some releases have "more in them", but > that is difficult to quantify and in my opinion, not an especially > useful metric by which to distinguish releases. > > So why not always do minor releases unless a release really is > ABI-compatible? It's not like we're going to run out of numbers, Gnome > is on 2.28 (they don't seem to bother with a subminor number at all, > presumably because they just don't make that sort of release). > > Note that I'm not suggesting that subminor numbers be used in place of > patch levels since those are purely bug fixes and contain no new > functionality.
Each time this issue comes up - we go though a list of rationale and slightly modify the naming convention. And we never land at the orignial-intended convention you are refering to. Perhaps one rationale used was: Currently linux-kernel only changes the sub-minor version for any and all changes - so current petsc scheme is equivalent, [instead of .p1,.p2, linux kernel uses an extra .1,.2 etc..] and no need for petsc to adhere to the original convention. [Also as you indicate - gnome also doesn't conform - by removing subminor release number] Are you sugesting going from: petsc-3.0.0-p0.tar.gz petsc-3.0.0-p1.tar.gz to: petsc-3.1.0-p0.tar.gz or petsc-3.1-p0.tar.gz The alternative - not suggested is: petsc-3.1.0.tar.gz petsc-3.1.1.tar.gz etc.. [if changing - I guess I don't mind the third one - provided the curent workflow is preserved.]. Any change is bound to create some confusion with users.. Satish
