On Mon, 16 Jun 2014, Barry Smith wrote: > >> My feeling is that ONLY a git OR a .tar.gz should be listed at any one > >> time and not both at the same time (the other should be commented out). > > > > The issue is - that would require all users having git installed. > > Releases would ONLY list tar balls. Branches in petsc-dev (in git) could > list either a tar ball or a git repository. Hence end users do not need git. > > This would require that when making a release branch any git based urls > would need to be replaced with tar ball ones. Which we kind of need anyways.
Either both are equivalent [and should work with both releases and dev snapshots] - or its too combersome - so only tarballs should be used for both releases and dev snapshots. I don't see why one should use git urls for dev and change them to tarball urls for release [which is error prone and fragile] > >> I think the correct fix is for the values in moab.py (for each package) > >> are changed over time and may be different in different branches and then > >> at a release they are “locked” into the correct value for that release. > >> Yes, this may mean manually setting some of the values when the release > >> branch is made. Tough, there is no way around it. > > > > This is fine by me. This is what we do with every other package. We > > could keep updating moab-snapshot-xxx.tar.gz as required. > > > > Thei issue came with MOAB becase at some point we decided 'petsc-dev > > should always use latest moab-dev’. > > well no. moab.py had hardwired some ancient git version of moab while the > tar ball that it used was the nightly. So the git version did not match the > tar ball version! > I consider 'hardcoding' git version' a bug. It should match the url. gitversion = 'HEAD' [or equivalent] would have matched moab-nightly approximately. If the match is not possible - one of them should be removed. [if git was prefered - then the tarball wold not have been tested. Currently tarball, git-clone have different install procedures - complexity that I don't like - but someone insisted that we need both] However there is a fundamental problem with 'petsc-dev should always use latest moab-dev, petsc-release should use moab-release’ For one - releases should be synced - and then there is all this extra manual change for every release - before and after [there is already a bit list of manual changes required during release time]. Secondly we have some users who freeze old petsc-dev snapshots [and upgrade at a different schedule]. They are likely to have inconsistant moab. [so I think its best to avoid listing moab-nightly as a default in petsc-dev branches] Satish
