[petsc-dev] release naming scheme

[Jed Brown]

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

> Right now PETSC_VERSION_PATCH_DATE is automatically set when the
> tarball is spun. [And we also have PETSC_VERSION_DATE_GIT - primarily
> for configure.log]
>
> So your suggestion is to remove PETSC_VERSION_PATCH_DATE - and set
> PETSC_VERSION_DATE [automatically during tarball creation]

Yes, is there a reason not to do this?  Having two dates is more
complexity and I don't see the benefit.

> Also - I see petscnagupgrade.py checks
> http://www.mcs.anl.gov/petsc/petsc-dev/include/petscversion.h for
> latest release version info. So for the old versions [of petsc
> petscnagupgrade.py] to work - we'll have to retain PETSC_VERSION_PATCH
> [as you suggested]

The commit below is in 'jed/nagupgrade-subminor'.  Since 3.4 will
increase MINOR, the old script will still ask people to upgrade to 3.4.

commit e9b81f52c562140219af174f5ca7d2825fc8b69f
Author: Jed Brown <jedbrown at mcs.anl.gov>
Date:   Sun May 12 13:20:52 2013 -0500

    nagupgrade: check subminor version and use distutils.version
    
    Subminor version will be used for maintenance releases starting with the
    3.4 series.
    
    Version comparison is simpler with distutils.version.

> BTW: before switching the scripts to handle the new version naming - I
> created petsc-3.3-p7 tarballs with the current outstanding patches in
> the maint branch [via balay/maint-3.3-p7 branch]. If its ok - it can
> be merged into maint/master.
>
> ftp://ftp.mcs.anl.gov/pub/petsc/release-snapshots/petsc-3.3-p7.tar.gz
> [web page isn't updated though]

Sounds good to me.