[aur-general] Revise VCS packages versioning

[Jason St. John]

On Thu, Oct 31, 2013 at 2:26 PM, Anatol Pomozov
<anatol.pomozov at gmail.com> wrote:
> Hi
>
>> The sha1 is useful to people who need to quickly tell developers which
>> version they are running when they're from git. Removing it is a bad
>> idea.
>
> You can get the commit from the version number even without the SHA1,
> something like:
>
> git log --oneline $VERSION..$BRANCH | tail -n $REVISION | head -n 1
>
> Where $BRANCH is the one used in PKGBUILD (usually it is HEAD).
>

It's a lot easier to get the commit ID by running "pacman -Qi
<pkgname>". I'd rather do that than have to potentially redownload the
Git sources and search the commit log.

>
> Anyway VCS-package users suppose to follow HEAD version closely. In
> those rare cases when a user sees problem in no-release non-HEAD
> version and tries to contact upstream developers I bet the first
> question from the developers will be "Could you please update to HEAD
> and see if the problem still exists?".
>

That's certainly true; however, it is useful to know which commits
still have a problem. So sending a non-HEAD commit ID is still
somewhat helpful even if upstream asks the bug reporter to test again
using HEAD.

>> The main issue with -git versioning is the inconsistency. The proto
>> file for it is terribly out of date, not everyone respects whatever
>> flavour of the recommended way is current, and not every git
>> repository has tags (creating a need for two different functions, the
>> need of which cannot be told until build time). A further issue arises
>> from that, which is that repositories without tags may get tags later
>> on and the package maintainer may not know about that (leaving the old
>> versioning in), or using the new versioning may break versioning for
>> other packages.
>>
>> I'm not suggesting we drop the pkgver function (nobody is). I'm saying
>> we need a standardized pkgver script that outputs consistent,
>> compatible results between tagged and non-tagged git repos, and
>> recommend that as the proto. To that end, I liked the proposal of
>> 0.7.r19.ge4e6e20 vs 0.r19.ge4e6e20.
>>
>> J. Leclanche

Jason