> Yes, the date is known by everyone. But, on the other hand - users has only
> interested in "it's newer?" This will recognize easily using 'pre' numbers.
> And when user wants to us - developers - to tell which version have, we
> prefer for git hash. And user will be able to provide git hash.
> 
> Date is less useful for us. Find the appropriate git hash requires extra work.
> And 'pre' number i combination with git hash therefore provides information
> for both - for users and also for developers. Bear in mind that this
> designation applies only to development versions.

Okay. I understand your point. As I mentioned, I'm not against the idea.

Unless there are objections, seems we could proceed with the following package name guideline:

* Use the text string "trinity" in the package name. Whether the string is a prefix to the base name or a suffix is not important. This applies to both development branch packages and official release packages.

* Use a "pre" number and the module GIT hash in the package name. This applies only to development branch packages. To generate this information, use the following commands in build scripts:

cd [module name]
git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l
cat .git/ORIG_HEAD | cut -c 1-8

The result will look something like this:

tdelibs-trinity-14.0.0~pre385+189c12d0
tdelibs-trinity-3.5.13.2~pre12+205b3397

Or

trinity-tdelibs-14.0.0~pre385+189c12d0
trinity-tdelibs-3.5.13.2~pre12+205b3397

* The remainder of the package name is distro-specific.

Does this sound agreeable to everybody?

Darrell