15 Nov
2012
15 Nov
'12
midnight
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