Jeff,
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'
or
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'
Cheers,
Gilles
On 10/18/2016 5:17 AM, Jeff Squyres (jsquyres) wrote:
SHORT VERSION
=============
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:
openmpi-${BRANCHNAME}-${YYYYMMDD}-${SHORTHASH}.tar.bz2
Here's what last night's tarballs would have looked like with that scheme:
openmpi-master-20161017-bd1b6fe.tar.bz2
openmpi-v2.0.x-20161017-a66f3e2.tar.bz2
openmpi-v2.x-20161017-56991c6.tar.bz2
Optionally, we could put a HHMM timestamp in there for finer granularity.
MORE DETAIL
===========
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
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
