::: From my experience most of the tags do not contain any dashes and simpler sed expression can be used. There are some projects that use dashes e.g. {{ic|1.2-alpha}} and in this case you are right - the more complicated sed expression should be used to handle it correctly.

:So Git makes some projects jump down from {{ic|x.x.x.210}} to {{ic|x.x.x.x.50}}? Is that really intended behavior?

:So Git makes some projects jump down from {{ic|x.x.x.210}} to {{ic|x.x.x.x.50}}? Is that really intended behavior?

Line 77:

Line 86:

:::{{ic|r}} prefix is fine with me. We also need to cut leading {{ic|v}} from the version returned by git. Here is slightly modified {{ic|pkgver()}} used by {{AUR|tup-git}} package {{ic|<nowiki>git describe | sed -E 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'</nowiki>}}

:::{{ic|r}} prefix is fine with me. We also need to cut leading {{ic|v}} from the version returned by git. Here is slightly modified {{ic|pkgver()}} used by {{AUR|tup-git}} package {{ic|<nowiki>git describe | sed -E 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'</nowiki>}}

::::I'd like to see a more visible separator between the different parts of the version number, I suggest {{ic|+}} <br />{{ic|<nowiki>git describe | sed -E 's/^v//;s/-([^-]*-g)/+r\1/;s/-/+/g'</nowiki>}}

The download example can still be found in /usr/share/pacman/. The next version of the ABS package should update it a bit so the download happens in the prepare function where it belongs. As for pkgver, I think the generic example using date covers that, as there's not a way to get a version number from a CVS repo. Maybe a note to that effect?

That makes the most sense, but it might also be a good idea to rename the "Fallback" section to something like "Fallback / CVS" to make it more obvious even when you're just checking out the table of contents.

But as for ABS, as far as I can tell the last commit was over 8 months ago.

Hmm, there were a number of patches submitted last month for cleaning up the prototypes, looks like none have been committed yet. I do remember a discussion (IRC maybe?) questioning the proper place for the prototypes, so maybe that's why? Looking at the patches, I was mistaken anyway; they didn't update the darcs or cvs prototypes. Simple enough, I'll send in a patch myself.

More on git pkgver()'s

so they are more friendly to vercmp.
Current behaviour using git-git as an example:

current ver: 1.8.2.210.g123abc-1
next ver: 1.8.2.1.50.g123abc-1

vercmp 1.8.2.210.g123abc 1.8.2.1.50.g123abc
1 # the first is greater than the second

Right now, the current version is actually greater than the new version, causing a downgrade. If r is appended to the patch level (the numbers just before the g<hex> bit), then vercmp would order the versions correctly.

current ver: 1.8.2.r210.g123abc-1
next ver: 1.8.2.1.r50.g123abc-1

vercmp 1.8.2.r210.g123abc 1.8.2.1.r50.g123abc
-1 # the first is less than the second

From my experience most of the tags do not contain any dashes and simpler sed expression can be used. There are some projects that use dashes e.g. 1.2-alpha and in this case you are right - the more complicated sed expression should be used to handle it correctly.

I have the same issue with tup-gitAUR package that bumped its version from 0.6 to 0.6.5. previously generated version was 0.6.350.gfoobar now it became 0.6.5 that is smaller than previous. Generated version should split upstream version from git describe version. My vote is goes to ~ delimiter proposed above. Or maybe we can use - as delimiter?

r prefix is fine with me. We also need to cut leading v from the version returned by git. Here is slightly modified pkgver() used by tup-gitAUR package git describe | sed -E 's/^v//;s/([^-]*-g)/r\1/;s/-/./g'

git pkgver: Date of last commit at the beginning of the version number for compatibility with older PKGBUILDs from AUR?

We have quite a bunch of older PKGBUILDs for -git packages in AUR which still work but which do not have a pkgver function yet. Many of these actually carry a date as version number (mostly the date of the last git commit at the time when the PKGBUILD was last updated).

When you update these scripts to use one of the two pkgver functions suggested on the wiki page, AUR helpers like packer will (in most cases) suggest that there is a newer version in AUR on every system update. My proposal to solve this problem is a pkgver function which precedes the generated version number with the date of the last git commit:

This function is *not* intended to go into PKGBUILDs in AUR, but could be proposed as a temporary "local" fix in the wiki for the period of time until the package maintainer has found time to update his PKGBUILD in AUR.