Le 27/09/2013 15:36, Jeff Squyres (jsquyres) a écrit : > I'd say that git and the new Trac are now fully open for business. I might > still do some shifting around of tags (see below), but otherwise, I think > everything is just about ready. > > I'm revamping make_dist_script and the nightly build script; I should finally > be able to commit those today, if all goes well. However, I had to make some > changes to VERSION and some other surrounding infrastructure to make it all > work. Specifically: git just does some things *differently* than SVN, so it > required some changes in the way that hwloc does things, infrastructure-wise. > > > Two things: > > 1. I'm not excited about back-porting these changes all the way back to > hwloc-1.0 just so that we can make nightly tarballs for these branches which > aren't used any more. I'm thinking that I should definitely make these > changes for master and the v1.7 branch. Should I also do the v1.6 branch?
I don't think so. I am planning to only update the regression testing for v1.7 as well. BUT what if the stable OMPI 1.6 needs a hwloc fix? Should we keep the hwloc v1.5 branch open? > 2. With SVN, adding the r number in the tarball version was sufficient to > observe ordering of the tarballs. For example: > > hwloc-1.8r1234.tar.bz2 > hwloc-1.8r1240.tar.bz2 > hwloc-1.8r1255.tar.bz2 > ...etc. > > With git, we only have a hash number. So there's no obvious ordering of the > tarballs. For example: > > hwloc-1.8git11223344.tar.bz2 > hwloc-1.8git00aa3344.tar.bz2 > hwloc-1.8git99aa2277.tar.bz2 > ...etc. > > However, there is "git describe" functionality which, in our case, can show > you how many commits you are beyond a given tag. For example, I added a > "dev" tag on the master branch for the first pure-git commit (i.e., 1 beyond > the last SVN commit). For example: > > $ git clone g...@github.com:open-mpi/hwloc.git > ...clone completes successfully... > $ cd hwloc > $ git checkout master > $ git describe --always > dev-3-g51efdd1 > > Where the "3" represents that we're 3 commits beyond the "dev" tag. The "g" > just means "git", and the "51efdd1" is the hash of that commit. > > Hence, if we use that as our version string, we get tarballs named something > like this: > > hwloc-dev-3-g51efdd1.tar.bz2 > hwloc-dev-10-gf50a385.tar.bz2 > ...etc. > > For the master branch, I think that's fine. However, note that ***THIS IS > DIFFERENT THAN WHAT WE HAVE PREVIOUSLY DONE ON RELEASE BRANCHES!*** > > For example, if you checkout the v1.7 branch: > > $ git checkout v1.7 > $ git describe --always > hwloc-1.7.2-4-g3a6f84c > > *** NOTE THE DIFFERENCE HERE: > > a) The last SVN nightly snapshot on the v1.7 branch was named > hwloc-1.7.3rc1r5779.tar.bz2. > b) The first git nightly snapshot on the v1.7 branch will be named > hwloc-1.7.2-4-g3a6f84c.tar.bz2. > > Note "1.7.3rc1..." vs. "1.7.2...". I.e., the git name will say "we're X > commits beyond the 1.7.2 tag", but the old SVN name was "we're at this > *upcoming* version". > > I think that this is ok (other projects use this "git describe" kind of > behavior for their nightly snapshots), but this is a change from what we used > to do, so I wanted to call it out specifically. > > Are you guys ok with this? > That'll work for me. What about when we are actually doing a release where we don't want a git-describe suffix ? Does the above apply to contrib/make_dist_tarball in general? Or only to when it runs at night (in make dist only?) ? Brice
