[petsc-dev] significance of version numbers

[Kai Germaschewski]

Let me just put in my 0.02 cents (yes, I know that's less than 2 cents), to
say I'd prefer 3.1, 3.1p1, .., 3.2, 3.2p1 etc. unless there's a a distinct
criterion to distinguish between minor and subminor releases. (IMO, major
releases are only rarely justified, for example when going from a C to a
Python based core or some other really fundamental change. Of course there
may be other factors, like funding politics...)

Actually, I'd normally prefer 3.1.0, 3.1.1, .., 3.2.0, 3.2.1, but the former
should cause less confusion considering petsc's historical numbering.

I'm certainly one of those people who's been thinking, "one shouldn't put
those kind of changes into a subminor release" before, which really only
goes to show my ignorance on petsc's (unusual) policy. But, if there is a
sort of established way on how to do things, I usually favor following that
way, even if one has arguments why the proprietary way actually makes more
sense.

--Kai


On Mon, Mar 8, 2010 at 4:45 AM, Jed Brown <jed at 59a2.org> wrote:

> On Sat, 6 Mar 2010 17:12:33 -0600, Barry Smith <bsmith at mcs.anl.gov> wrote:
> >
> >     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.
>
> Thanks for the explanation.  I actually brought this up in response to
> comments I've heard from users and other libs that depend on PETSc, to
> the effect of, "What are they thinking changing X in a subminor
> release?"  So it's not just me, but perhaps the users that ascribe a
> precise meaning to minor vs. subminor version numbers are still in the
> minority.
>
> Jed
>



-- 
Kai Germaschewski
Assistant Professor, Dept of Physics / Space Science Center
University of New Hampshire, Durham, NH 03824
office: Morse Hall 245F
phone:  +1-603-862-2912
fax: +1-603-862-2771
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100308/de15d233/attachment.html>