On 12/24/2011 11:48 AM, Darrell Anderson wrote:
> With SVN I used a package naming scheme based upon the previous official release number and SVN version:
>
> kdebase-3.5.12-125202-i486-1.txz
>
> With the official tarballs the package name excluded the SVN version:
>
> kdebase-3.5.13-i486-1.txz
>
> I expect to continue that naming scheme with official release tarballs, although the version numbers change:
>
> kdebase-r14.0-i486-1.txz
>
> Enter GIT.
>
> GIT uses a weird hash number for each patch version. Is there a more straightforward version number? Or will I have to start naming GIT builds using a date and time scheme?
>
> kdebase-20120101_2200-i486-1.txz
>
> More generally, should we adopt a common package naming scheme, as much as possible within the limitations of each distro's package naming conventions? Might be nice if all of us use a somewhat similar naming scheme.
>
> Ideas? Comments?
>
> Darrell

I am working with this also.

What I am thinking I will do is this, which is along the lines you are 
considering....

packagename-git-date.tar.xz

example: tdelibs-git-2011-12-24.tar.xz

Then I am going to build like once a week, automated of course.
I will have two scripts the first on will git clone the package(s) and 
make a tarball, sed the version numbering in the build script.
The second one will then do the build.

May not workout that way but that is my plan so far.

This is from my build script,  tested it works for me.
Well I am testing it now and it seems to be working.....
It will change when I go to git as this one fetchs the 3.5.13 version, I 
will remove the pushd git popd so it will give me the master

mksource() {
     git clone http://scm.trinitydesktop.org/scm/git/${pkgname}
     pushd ${pkgname}
         git checkout v3.5.13
     popd
     tar -cvJf ${pkgname}-${pkgver}.tar.xz ${pkgname}/*
}

Gives me a source tarball like this tdelibs-3.5.13.tar.xz

Maybe that helps?