[petsc-dev] PETSC_VERSION of dev branches

[Satish Balay]

On Thu, 12 Dec 2013, Satish Balay wrote:

> On Thu, 12 Dec 2013, Dmitry Karpeyev wrote:
> 
> > 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.
> 
> As mentioned 3.4.3 has no baring on master. only PETSC_VERSION_RELEASE==0 is relavent.
> 
> > 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
> 
> I don't see a problem here [except for the extra '&&
> PETSC_VERSION_RELEASE' which shouldn't be needed.
> 
> 
> > Note that I can't always use the more succinct PETSC_VERSION_LT(),
> > since it doesn't exist before something like petsc-3.3.
> 
> Presumably PETSC_VERSION_LESS_THAN() is the macro you created. Why not
> just copy over PETSC_VERSION_LT() exactly as-is [with dependent
> macros] - and call it PETSC_VERSION_LESS_THAN() [or equivalent name] -
> if you need to maintain compatibility for petsc-3.2 or older.

i.e


#define PETSC_VERSION_LESS_THAN(MAJOR,MINOR,SUBMINOR)   \
  (PETSC_VERSION_RELEASE == 1 &&                        \
   (PETSC_VERSION_MAJOR < (MAJOR) ||                    \
    (PETSC_VERSION_MAJOR == (MAJOR) &&                  \
     (PETSC_VERSION_MINOR < (MINOR) ||                  \
      (PETSC_VERSION_MINOR == (MINOR) &&                \
       (PETSC_VERSION_SUBMINOR < (SUBMINOR)))))))

#if PETSC_VERSION_LESS_THAN(3,3,0)
/* petsc-3.2.x or older compatibility code */
#elif PETSC_VERSION_LESS_THAN(3,4,0)
/* petsc-3.3.x compatibility code */
#elif PETSC_VERSION_LESS_THAN(3,5,0)
/* petsc-3.4.x compatibility code */
#else
/* petsc-master compatible code */
#endif

Satish
> 
> > 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.
> 
> I don't understand which part looks odd - and how adding a version
> numer to petsc-master helps here.
> 
> Satish
> 
> > 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.
> > > >
> > >
> > >
> > 
> 
>