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
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/$%7Bpkgname%7D 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?
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?
<snip>
The Debian/Ubuntu builds utilize the revision *count*, that is, the number of commits that have been made to each module.
You can get this number by using the following (nasty, complex, and completely unobvious) command: git shortlog . | grep -E '^[ ]+\w+' | wc -l
SVN was much easier in this regard. ;-)
Tim
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?
<snip>
The Debian/Ubuntu builds utilize the revision *count*, that is, the number of commits that have been made to each module.
You can get this number by using the following (nasty, complex, and completely unobvious) command: git shortlog . | grep -E '^[ ]+\w+' | wc -l
SVN was much easier in this regard. ;-)
Tim
Also I should mention that it is a good idea to include the full GIT hash in a changelog somewhere, because there is no way to easily go from the revision count to the GIT hash as listed on the TDE patches page.
Tim
The Debian/Ubuntu builds utilize the revision *count*,
that is, the number
of commits that have been made to each module.
You can get this number by using the following (nasty,
complex, and
completely unobvious) command: git shortlog . | grep -E '^[ ]+\w+' | wc -l
SVN was much easier in this regard. ;-)
I don't yet have the GIT repository synced to my system. What would this naming scheme look like?
Should we agree to a relatively common package naming scheme for all packagers?
Darrell
The Debian/Ubuntu builds utilize the revision *count*,
that is, the number
of commits that have been made to each module.
You can get this number by using the following (nasty,
complex, and
completely unobvious) command: git shortlog . | grep -E '^[ ]+\w+' | wc -l
SVN was much easier in this regard. ;-)
I don't yet have the GIT repository synced to my system. What would this naming scheme look like?
I use this: arts-trinity - 4:14.0.0-0debian0+r49+pr4~wheezy
14.0.0 is the TDE version, 0debian0 is Debian specific and normally increments on any required rebuilds, r49 is the TDE source revision of the arts module, pr4 is the Debian packaging revision of the arts module, and ~wheezy is the distro version's codename.
Should we agree to a relatively common package naming scheme for all packagers?
We can try, but I'll play it by ear. :-) I have no desire to change the Debian scheme, as it might badly break upgrades for Debian/Ubuntu users.
Tim
I use this: arts-trinity - 4:14.0.0-0debian0+r49+pr4~wheezy
14.0.0 is the TDE version, 0debian0 is Debian specific and normally increments on any required rebuilds, r49 is the TDE source revision of the arts module, pr4 is the Debian packaging revision of the arts module, and ~wheezy is the distro version's codename.
I see the release version is three numbers. GIT versions will change daily, but if the official release number changes does that mean official tarballs will be released too?
Version 14.0.0: new tarballs Version 14.0.1: new tarballs Version 14.1.0: new tarballs
Only developers and testers will be concerned with the GIT release numbers?
I'm thinking packagers should avoid using the GIT version in the package name if the package is built with an official tarball release.
Official tarball releases: arts-14.0.0-i486-1.txz arts-14.0.1-i486-1.txz arts-14.1.0-i486-1.txz
GIT packages: arts-14.0.0_r2371-i486-1.txz arts-14.0.1_r2771-i486-1.txz arts-14.1.0_r3071-i486-1.txz
Users then know that packages with GIT versions are unofficial testing packages and not official releases.
Sound good?
Darrell
-
Baho Utot -
Darrell Anderson -
Timothy Pearson