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