On Sun, Sep 29, 2013 at 5:20 AM, Jeff Squyres (jsquyres) <jsquyres_at_[hidden]
> 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.
> 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
Who knows, maybe we'll just end up using git describe for its simplicity.
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900