On Thursday 15 of November 2012 01:00:13 Darrell Anderson wrote:
> > 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:
> * The remainder of the package name is distro-specific.
> Does this sound agreeable to everybody?
I tried to prepare a script that under the proposed rules create a tarball for
module from the active folder. In the script is solved searching for last tag
in current branch. Besides, are added checks if the current tree corresponds
to the state on the server. And it is also added support for the creation of
the final tarballs, when the number of commits since the last tag is zero.
Please, test it. If it proved to be useful, script could be added into the git