You make a valid point - I too prefer simplicity to a 50-character-long name.
There should be some simple way of making it clear which branch the tarball
came from...your suggestions seem reasonable and easy to do. I’m sure we’ll be
talking about this on the telecon in the morning.
> On Oct 17, 2016, at 8:56 PM, Gilles Gouaillardet <gil...@rist.or.jp> wrote:
>
> 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
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
