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.
