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
