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...)<br>
<br>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.<br><br>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.<br>
<br>--Kai<br><br><br><div class="gmail_quote">On Mon, Mar 8, 2010 at 4:45 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@59a2.org">jed@59a2.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Sat, 6 Mar 2010 17:12:33 -0600, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
>     I have no objection to making each PETSc release crank up the<br>
> second digit. And organizing the numbers as 3.1-pX then 3.2-pX etc.<br>
><br>
>     Historical explanation why we had the strange numbering before.<br>
> 1) Most PETSc users don't know anything about "Open source standards<br>
> for release numbers" so we didn't feel a need to use it. It is only<br>
> the occasional oddball like you that ever comments on this.<br>
> 2) We use to make releases far more often, then I didn't like the idea<br>
> of always cranking up the second digit since I felt it implied some<br>
> relatively large changes in the libraries when there really were not<br>
> any. So, yes it was somewhat arbitrary but not random.<br>
<br>
</div>Thanks for the explanation.  I actually brought this up in response to<br>
comments I've heard from users and other libs that depend on PETSc, to<br>
the effect of, "What are they thinking changing X in a subminor<br>
release?"  So it's not just me, but perhaps the users that ascribe a<br>
precise meaning to minor vs. subminor version numbers are still in the<br>
minority.<br>
<font color="#888888"><br>
Jed<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Kai Germaschewski<br>Assistant Professor, Dept of Physics / Space Science Center<br>University of New Hampshire, Durham, NH 03824<br>office: Morse Hall 245F<br>phone:  +1-603-862-2912<br>
fax: +1-603-862-2771<br><br>