On Sun, Sep 29, 2013 at 5:20 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com > wrote:
[snip] > The only branch that didn't have any tags at all was master, so I just > created a "dev" tag on master, and that was sufficient. Right, we plan to use the gitflow model in which master contains released code and a "develop" branch serves the role of the svn trunk or cvs head as the target for 99% of commits. Since as I understand it, "git describe" counts from the most recent tag, if we used git describe for tarballs we probably apply a tag to the develop branch which names the upcoming release. Perhaps "v1.7.3devel". Even if master is your development branch, applying a more descriptive tag is something you might consider. [snip] > That being said, when we tell users to get a nightly tarball (e.g., to get > a bug fix), my experience is that they don't know/care about the nightly > tarball numbering scheme: they always just get the most recent version. The advantage isn't only for the user. When somebody reports "I found a bug when trying nightly tarball <whatever>.tar.gz" it seems useful to me to (without leaving my email client) know "that was 8 days ago and I *know* we fixed <blah> since then". With just a hash I am likely to defer my response until I have a moment to correlate the hash to a date. This is NOT a big deal, just an observation that having the date in the filename makes talking about "it" more meaningful. Who knows, maybe we'll just end up using git describe for its simplicity. -Paul -- Paul H. Hargrove phhargr...@lbl.gov Future Technologies Group Computer and Data Sciences Department Tel: +1-510-495-2352 Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
