> > This is an unnecessarily long. Date information can be misleading - not
> > related to the date of GIT version. Not solve the correct sequence of
> > multiple versions in one day. In this case, the "meaningless number" is
> > more neutral. Simply only going to increase with each pre-release.
> 
> It occurred to me - the number would not be "meaningless" - for example,
> it could be the number of commits since the last release. For example:
> 
> cd tde/main/tdelibs && git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l
> 
> This would automatically resets this number after each official release.
> 
> What do you think?

For the development branch, part of the package name should convey information that we all are packaging in a similar manner.

Thus, whether we name a package krita-trinity or trinity-krita is not as important as we all consistently use the text string "trinity."

Likewise for conveying GIT snapshot information about the package.

I ran the command above:

git log $(git tag | sort | tail -n1)..HEAD --pretty=oneline | wc -l
384

The result "384" conveys little information to end-users. That is, end-users would not be able to know from that number the snapshot moment of the package.

Our goal should be to adopt a package naming scheme that ensures a reasonable degree of consistency among all packagers. There is no way for all of us to have the exact same text strings in the packages because each distro is different. None of us create packages at the exact same moment. We are only seeking a reasonable degree of consistency.

Using dates or hashes is sensible but only when we use them consistently.

My concern with hashes is they are gibberish when used by themselves. They convey no useful information by themselves.

Dates make sense to me when related to the snapshot moment of the repository. Dates do not make sense to me when representing when the package was created. Nothing stops a person from updating a local repository and then building packages from that snapshot a week later. In such an example the date provides no meaningful information. When a person builds a package a week later but the date represents the snapshot moment of the repository then the date retains meaning.

Because of the recent server updates, I have not updated my local repository for several days. At this moment in my local repository, the date/time stamp of tdelibs/.git/ORIG_HEAD is Nov 10 11:46. I could convert that to 201211101146 or some other combination such as 2012_11_10_11_46. With that method I don't need to extract a hash from anywhere.

I could use both date and a hash: 20121110-03733ab1 or 201211101146-03733ab1. The hash and time stamp will change with each patch pushed, even when there are multiple pushes during a day. Thus, both date-hash and date-time convey useful information about the repository snapshot moment. Yet to end-users, I believe a date-time string conveys more useful information.

The following command extracts the date-time:

find tdelibs/.git/ORIG_HEAD -printf "%TY%Tm%Td%TH%TM\n"
201211101146

I could extract the module's most recent hash:

cat tdelibs/.git/ORIG_HEAD | cut -c 1-8
03733ab1

With all of that said, the git shortlog method I have been using runs into the same challenge. The number has meaning to me because the number is always increasing. A date is a much better informational guide. We only need agree on a consistent way to extract that date from the module. :)

Darrell