[petsc-dev] release naming scheme

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

>> What is the utility of PETSC_VERSION_PATCH_DATE?
>
> In the current scheme we have: [for each petsc-3.3-pX tarball]
>
> PETSC_VERSION_DATE: date of the primary release [i.e when the first 3.3 tarball was spun]
> PETSC_VERSION_PATCH_DATE: date of the patched tarball release [i.e when 3.3-pX was spun]
>
> And we use PETSC_VERSION_DATE [manually transcribed] in a bunch of
> places.
>
> - https://www.mcs.anl.gov/petsc/
> "The current version of PETSc is 3.3; released June 5, 2012"
>
> - https://www.mcs.anl.gov/petsc/documentation/changes/index.html
>
> - manual
>
> But PETSC_VERSION_PATCH_DATE: is the date the tarball is respun [with
> patches] - and that doesn't change the above docs.

How is this information useful?  Would it be simple enough to "release"
the manual once per feature release (3.4, 3.5, ...) so that it's date
would not need to be updated every maintenance (subminor) release and
then PETSC_VERSION_DATE would always reflect the date of the last
release?

We could stop hard-coding these values and switch to obtaining them from
Git, in which case releasing would just involve tagging and spinning the
tarballs, but that automation can wait.