[petsc-dev] PETSC_VERSION of dev branches

[Dmitry Karpeyev]

On Thu, Dec 12, 2013 at 5:05 PM, Satish Balay <balay at mcs.anl.gov> wrote:

> On Thu, 12 Dec 2013, Dmitry Karpeyev wrote:
>
> > Is there any reason 'master' has PETSC_VERSION equal to the latest patch
> > release version,
> > rather than the first upcoming release version?
>
> All changes to petscversion.h in maint get merged to master.
>
Yes, I see the problem.  I don't necessarily have a (good) solution, short
of creating
a separate branch for each patch release (e.g., maint-3.4.3).  Those could
be ahead
of maint by a single commit such as those that are currently used to
increment the patch level.

>
> And 'PETSC_VERSION_RELEASE'  0 vs 1 is supporsed to identify petsc-dev.
>
> > Surely, the use of PETSC_VERSION_LT() makes it relatively easy to guard
> > against API changes in derived software, but it's a bit odd to see
> > #if PETSC_VERSION_LT(3,5,0)
> > /* Works for petsc-3.4.x and earlier. */
> > #else
> > /* Supposed to work petsc-3.4.x as long as !PETSC_VERSION_RELEASE */
>
> It should be 'latest petsc master' here. 3.4.x doesn't have any meaning
> here..
>
Yes, but master today has version number 3.4.3.
In some code that depends on PETSc (e.g., libMesh) I have to use guards
like these:
#if PETSC_VERSION_LESS_THAN(3,5,0) && PETSC_VERSION_RELEASE
/* releases petsc-3.4.x and earlier. */
#else
/* master */
#endif
Note that I can't always use the more succinct PETSC_VERSION_LT(),
since it doesn't exist before something like petsc-3.3.  I could guard for
pesc-3.3
and then use the shorter macro inside, but that defeats the purpose.
Meanwhile, these additional PETSC_VERSION_RELEASE clauses look odd.
They could be removed after petsc-3.5 has been released, but that's another
maintenance headache...

Dmitry.

>
> Satish
>
> > #endif
> >
> > Besides, master's "version" changes with every patch release.
> > It might not be of much practical importance, but looks a bit strange, in
> > my opinion.
> > At least intuitively, I think of 'master' as a sort of 'release
> candidate'
> > for petsc-3.5.0.
> > Wouldn't it be natural to name it that way?  Is there a technical reason
> > not to?
> >
> > Dmitry.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131212/ea4a6ce5/attachment.html>