i have no strong objections against the new scheme.

that being said, i think i like the current one better ...

imho, the issue is the tag was put on a commit that is common to master and branch.

i guess we did :

git checkout master

git tag v2.x

git branch v2.x

what if we had done instead :
git checkout master
git checkout -b v2.x
git commit --allow-empty -m "forking the v2.x branch"
git tag v2.x

pro: i guess that would have produced the "expected" behavior.
cons: v2.x would be only on the v2.x branch, so the branch point is really the parent of the tag

regardless we want to change the way we tag, could we simply sed the git describe output instead ?
master : git describe | sed -e 's/v2.x-dev/master/g'
v2.x: git describe | sed -e 's/v2.0.1/v2.x/g'
v2.0.x: git describe | sed -e 's/v2.0.1/v2.0.x/g'
v2.x: git describe | sed -e 's/v2.0.1/v2.1.0a/g'
v2.0.x: git describe | sed -e 's/v2.0.1/v2.0.2a/g'



On 10/18/2016 5:17 AM, Jeff Squyres (jsquyres) wrote:

Our nightly snapshot tarball filenames have become confusing.  Here's the most 
recent on each branch:

- Master: openmpi-v2.x-dev-3019-gbd1b6fe.tar.bz2
- v2.0.x: openmpi-v2.0.1-93-g97511a1.tar.bz2
- v2.x:   openmpi-v2.0.1-203-g56991c6.tar.bz2

I propose changing them to the following format:


Here's what last night's tarballs would have looked like with that scheme:


Optionally, we could put a HHMM timestamp in there for finer granularity.


We use "git describe" to come up with the version strings for our nightly snapshot 
tarballs.  "git describe" shows you three things:

- the first tag that it finds going back along the git commit history
- the number of commits it had to traverse to find that tag
- the short hast of the HEAD commit

For lack of a longer explanation, the names of the current snapshots *do* make 
sense given our commit and tag history; they're just... weird.

After talking this through with a colleague today, I think we have two choices:

1. Continue to use the "git describe" output
2. Come up with a different scheme

Using git describe output means that we are reliant on git tags.  Funky placement of git 
tags -- including the moving of branches back from ompi-release to ompi -- is how we 
ended up in this situation.  This might constitute empirical evidence that "git 
describe" is not a good solution for this community.

Instead, perhaps we should make a new scheme.  We need two properties in the 
snapshot filenames:

1. Name of the branch that the tarball came from.
2. Easily sortable by a human (i.e., know that tarball X came before or after 
tarball Y).

Property #1 is self-evident (the branch name is in the filename); property #2 
comes from the timestamp.

NOTE: It may be desirable to add HHMM in there; it's not common, but 
*sometimes* we do make more than one snapshot in a day (e.g., if one snapshot 
is borked, so we fix it and then generate another snapshot).

devel mailing list

Reply via email to