> 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