[aur-general] Revise VCS packages versioning

[Jerome Leclanche]

On Thu, Oct 31, 2013 at 1:43 PM, Anatol Pomozov
<anatol.pomozov at gmail.com> wrote:
> Hi
>
> On Wed, Oct 30, 2013 at 10:47 PM, William Giokas <1007380 at gmail.com> wrote:
>> On Wed, Oct 30, 2013 at 09:49:11PM -0700, Anatol Pomozov wrote:
>>> Hi
>>>
>>> On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche <adys.wh at gmail.com> wrote:
>>> > As someone who maintains a lot of git packages, I wish, I really wish
>>> > there was a *standardized* way of writing a pkgver that would output
>>> > the appropriate format whether there are tags pushed upstream or not.
>>>
>>> That is what I intended to propose next.
>>>
>>> As the regexp become more complicated it is better if makepkg will
>>> take care of generating the package version. I think makepkg should
>>> have a shell function, something like 'generate_pkgver_vcs()' that
>>> user can use in pkgver().
>>>
>>> e.g.
>>>
>>> pkgver() {
>>>   cd repo
>>>   generate_pkgver_vcs()
>>> }
>>>
>>> This function will
>>> 1) Find what VCS is used
>>> 2) Generate appropriate VCS version
>>>
>>
>> I would urge you to look at one of the newer features of pacman,
>> makepkg-template. You can do such things as this very easily. I already
>> maintain a small and probably awful repository[1]/package[2] with a few
>> VCS pkgver functions that you can use. Mostly they have been taken from
>> the wiki, though I do have a nice, long sed expression that does the
>> 'r' prefixing (I wrote that talk article).
>>
>> [1]: http://git.kaictl.net/wgiokas/makepkg-templates.git/
>> [2]: https://aur.archlinux.org/packages/makepkg-templates-ks-git/
>>
>> --SNIP--
>>> >> Another issue is a repo that has no tags. Here is a recommendation
>>> >> from the wiki page:
>>> >>
>>> >> printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
>>> >>
>>> >> that will use number of commits (a large number e.g. 3000). The
>>> >> problem arises when the project creates first tag e.g. 0.1. I suggest
>>> >> to fix this problem by using "0" as a tag version (and add prefix 'r'
>>> >> like in the previous item). This makes sure that non-tagged version is
>>> >> always less that a tagged version.
>>> >>
>>> >> So pkgver() will look like:
>>> >>
>>> >> printf "0.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
>>> >>
>>> >> Let me know if you have any objections. If not then I'll update the wiki page.
>>
>> This is not needed at all. If the project starts using tags, use an
>> epoch= to set all versions from then on to be greater than the original
>> versions with rev-list.
>
> Personally I do not like using epoch for such cases as it uglifies the
> version number.
>
> I see 2 options for non-tagged versions:
>
> 1) With "0." prefix. e.g. "0.r453". So beginning of the project
> history acts as a "release number zero" that is lower than any tagged
> version.
>
> 2) Without the prefix. e.g. "r453", it also works fine and makes the
> version a little bit shorter.
>
> $ vercmp 0.1 r543
> 1
>
>
> I prefer option #1 as it makes version more consistent between tagged
> and non-tagged versions, but I can live with #2 as well.
>
>
>
>
> BTW Most of the -git packages add 'short SHA1 of the HEAD'  as suffix
> e.g. '2.2.r9.g6c8d8ae-1'. In fact this SHA1 (g6c8d8ae in this example)
> is not used in the version comparison and not needed. I suggest to
> drop the SHA1 from recommended -git version and leave only the 'rXXX'
> part, e.g.
>
> 0.r32.gfoobar => 0.r31
> 2.2.r4.g23423234 => 2.2.r4
>
> This makes versions shorter and nicer, and makes it more consistent
> with other VCS.

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.

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