<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 12, 2013 at 5:05 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thu, 12 Dec 2013, Dmitry Karpeyev wrote:<br>
<br>
> Is there any reason 'master' has PETSC_VERSION equal to the latest patch<br>
> release version,<br>
> rather than the first upcoming release version?<br>
<br>
</div>All changes to petscversion.h in maint get merged to master.<br></blockquote><div>Yes, I see the problem.  I don't necessarily have a (good) solution, short of creating</div><div>a separate branch for each patch release (e.g., maint-3.4.3).  Those could be ahead</div>

<div>of maint by a single commit such as those that are currently used to increment the patch level. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
And 'PETSC_VERSION_RELEASE'  0 vs 1 is supporsed to identify petsc-dev.<br>
<div class="im"><br>
> Surely, the use of PETSC_VERSION_LT() makes it relatively easy to guard<br>
> against API changes in derived software, but it's a bit odd to see<br>
> #if PETSC_VERSION_LT(3,5,0)<br>
> /* Works for petsc-3.4.x and earlier. */<br>
> #else<br>
> /* Supposed to work petsc-3.4.x as long as !PETSC_VERSION_RELEASE */<br>
<br>
</div>It should be 'latest petsc master' here. 3.4.x doesn't have any meaning here..<br></blockquote><div>Yes, but master today has version number 3.4.3.</div><div>In some code that depends on PETSc (e.g., libMesh) I have to use guards like these:</div>

<div>#if PETSC_VERSION_LESS_THAN(3,5,0) && PETSC_VERSION_RELEASE</div><div>/* releases petsc-3.4.x and earlier. */</div><div>#else</div><div>/* master */</div><div>#endif </div><div>Note that I can't always use the more succinct PETSC_VERSION_LT(),</div>

<div>since it doesn't exist before something like petsc-3.3.  I could guard for pesc-3.3 </div><div>and then use the shorter macro inside, but that defeats the purpose.</div><div>Meanwhile, these additional PETSC_VERSION_RELEASE clauses look odd.</div>

<div>They could be removed after petsc-3.5 has been released, but that's another maintenance headache...</div><div><br></div><div>Dmitry.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<span class="HOEnZb"><font color="#888888"><br>
Satish<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> #endif<br>
><br>
> Besides, master's "version" changes with every patch release.<br>
> It might not be of much practical importance, but looks a bit strange, in<br>
> my opinion.<br>
> At least intuitively, I think of 'master' as a sort of 'release candidate'<br>
> for petsc-3.5.0.<br>
> Wouldn't it be natural to name it that way?  Is there a technical reason<br>
> not to?<br>
><br>
> Dmitry.<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>