On Sun, 12 May 2013, Jed Brown wrote: > 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.
For now I'll change: PETSC_VERSION_DATE -> PETSC_RELEASE_DATE PETSC_VERSION_PATCH_DATE -> PETSC_VERSION_DATE [and keep things as before.]. Too many changes before relese - and I'm not sure what could be breaking. > > 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. Yeah bunch of scripts need fixing with the new version scheme. > 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. ok merged to 'maint' and 'master' Satish
