[aur-general] Revise VCS packages versioning

newer
[aur-general] Signoff report for...

older
[aur-general] lxc-docker-git / maci

Anatol Pomozov

31 Oct 2013 31 Oct '13

4:37 a.m.

Hi I would like to discuss VCS package versioning that is described here https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines I am looking at the -git packages but it also applicable to other VCS. Here is the suggested way to create the version local ver="$(git describe --tags)" echo "${ver//-/.}" so 0.7-19-ge4e6e20 will turn into 0.7.19.ge4e6e20 The problem is that the revision number (19 in this case) looks like 3rd component in the version. Now imagine upstream project releases version 0.7.1. The generated version becomes 0.7.1 (and then 0.7.1.1.gfoobar). With the new tag the generated version becomes smaller (0.7.1.1 < 0.7.19). That is the real problem that I had with tup-git package - upstream uses both 2 and 3 component versions. We should recommend a way that works this case. There is a discussion in the comments and the best recommendation is to use following recipe: git describe | sed -E 's/([^-]*-g)/r\1/;s/-/./g' The idea is to find the commit number and start it with "r" (revision). "r" is smaller than a number so it will help in our case. 0.7-19-ge4e6e20 => 0.7.r19.ge4e6e20 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.

Show replies by date

Jerome Leclanche

31 Oct 31 Oct

4:51 a.m.

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. I like this proposal a lot. J. Leclanche On Thu, Oct 31, 2013 at 3:37 AM, Anatol Pomozov wrote:

...

Hi

I would like to discuss VCS package versioning that is described here https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines

I am looking at the -git packages but it also applicable to other VCS. Here is the suggested way to create the version

local ver="$(git describe --tags)" echo "${ver//-/.}"

so 0.7-19-ge4e6e20 will turn into 0.7.19.ge4e6e20

The problem is that the revision number (19 in this case) looks like 3rd component in the version. Now imagine upstream project releases version 0.7.1. The generated version becomes 0.7.1 (and then 0.7.1.1.gfoobar). With the new tag the generated version becomes smaller (0.7.1.1 < 0.7.19). That is the real problem that I had with tup-git package - upstream uses both 2 and 3 component versions.

We should recommend a way that works this case. There is a discussion in the comments and the best recommendation is to use following recipe:

git describe | sed -E 's/([^-]*-g)/r\1/;s/-/./g'

The idea is to find the commit number and start it with "r" (revision). "r" is smaller than a number so it will help in our case.

0.7-19-ge4e6e20 => 0.7.r19.ge4e6e20

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.

Anatol Pomozov

5:49 a.m.

Hi On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche 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 like this proposal a lot. J. Leclanche

On Thu, Oct 31, 2013 at 3:37 AM, Anatol Pomozov wrote:

...
Hi

I would like to discuss VCS package versioning that is described here https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines

I am looking at the -git packages but it also applicable to other VCS. Here is the suggested way to create the version

local ver="$(git describe --tags)" echo "${ver//-/.}"

so 0.7-19-ge4e6e20 will turn into 0.7.19.ge4e6e20

The problem is that the revision number (19 in this case) looks like 3rd component in the version. Now imagine upstream project releases version 0.7.1. The generated version becomes 0.7.1 (and then 0.7.1.1.gfoobar). With the new tag the generated version becomes smaller (0.7.1.1 < 0.7.19). That is the real problem that I had with tup-git package - upstream uses both 2 and 3 component versions.

We should recommend a way that works this case. There is a discussion in the comments and the best recommendation is to use following recipe:

git describe | sed -E 's/([^-]*-g)/r\1/;s/-/./g'

The idea is to find the commit number and start it with "r" (revision). "r" is smaller than a number so it will help in our case.

0.7-19-ge4e6e20 => 0.7.r19.ge4e6e20

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.

Doug Newgard

5:53 a.m.

----------------------------------------

...

Date: Wed, 30 Oct 2013 21:49:11 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche 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

Very, very bad idea. Every repo is different, the flexibility of the pkgver function lets the maintainer adapt to that. This was one of the major new features in pacman/makepkg 4.1. To be very blunt, if you can't figure out basic scripting enough to write a coherent pkgver function, you don't really have any business maintaining PKGBUILDs. The last thing we want it to go back to how it was done in < 4.1.

Anatol Pomozov

6:09 a.m.

Hi On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard wrote:

...

----------------------------------------

...
Date: Wed, 30 Oct 2013 21:49:11 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche 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

Very, very bad idea. Every repo is different, the flexibility of the pkgver function lets the maintainer adapt to that. This was one of the major new features in pacman/makepkg 4.1.

I do not propose to remove pkgver(). What I say is that vcs version generator becomes non-trivial and many people use different and inconsistent VCS versions. It indicates that there should be some standard way to generate version. If you don't want to use the standard generator you can use your own command to generate the version. But at least the standard generator will show how version should look like (e.g. "r" prefix or not, what delimiter should be used, etc)

...

To be very blunt, if you can't figure out basic scripting enough to write a coherent pkgver function, you don't really have any > business maintaining PKGBUILDs.

Please more respect, this is a public discussion.

Doug Newgard

6:15 a.m.

----------------------------------------

...

Date: Wed, 30 Oct 2013 22:09:21 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard wrote:

...
----------------------------------------

...
Date: Wed, 30 Oct 2013 21:49:11 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche 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

Very, very bad idea. Every repo is different, the flexibility of the pkgver function lets the maintainer adapt to that. This was one of the major new features in pacman/makepkg 4.1.

I do not propose to remove pkgver(). What I say is that vcs version generator becomes non-trivial and many people use different and inconsistent VCS versions. It indicates that there should be some standard way to generate version. If you don't want to use the standard generator you can use your own command to generate the version.

But at least the standard generator will show how version should look like (e.g. "r" prefix or not, what delimiter should be used, etc)

If you want the "r", add it. If not, don't. I don't see the problem.

...

...
To be very blunt, if you can't figure out basic scripting enough to write a coherent pkgver function, you don't really have any> business maintaining PKGBUILDs.

Please more respect, this is a public discussion.

I'm well aware that it's a public discussion, but I'm not going to sugar coat things to protect other's feelings. Bash can be complex, but basic scripting isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of the basics, you're being set up to fail from the get go.

Ido Rosen

6:32 a.m.

Anatol, Doug,

...

...
I do not propose to remove pkgver(). What I say is that vcs version generator becomes non-trivial and many people use different and inconsistent VCS versions. It indicates that there should be some standard way to generate version. If you don't want to use the standard generator you can use your own command to generate the version.

But at least the standard generator will show how version should look like (e.g. "r" prefix or not, what delimiter should be used, etc)

If you want the "r", add it. If not, don't. I don't see the problem.

...
...
To be very blunt, if you can't figure out basic scripting enough to

write a coherent pkgver function, you don't really have any> business maintaining PKGBUILDs.

...
Please more respect, this is a public discussion.

I'm well aware that it's a public discussion, but I'm not going to sugar coat things to protect other's feelings. Bash can be complex, but basic scripting isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of the basics, you're being set up to fail from the get go.

My reading of Anatol's post does not convey any lack of understanding of the basics of shell scriptings. I think you are misreading his original post, and responding ad hominem as a result of that misunderstanding. I read Anatol's original post as "please consider adding an optional convenience function that will handle the git describe / bzr revno / etc. for the packager and provide a sane default, while still allowing people to not use that function if they don't want to use it or if the git tag format doesn't play nicely with it." This seems like a reasonable suggestion: 99% of VCS packages have a simple pattern: strip the preceding letters up to the first number of some git describe or bzr branch name/revno string, then add the # of commits in this branch, then add the hash. Why not provide a convenience function to cover that? I agree with Doug that it's not a good idea, and here is the reasoning: (1) It's a write-once convenience function. If some developer changes the function upstream, it has the potential to break MANY VCS packages all at once, which would be very bad, so it is better for each VCS PKGBUILD to write its pkgver() specific to its own repository's organization/versioning (strong argument). (2) It's just extra baggage to carry for what is, for the most part, a one-liner in VCS packages right now (weak argument). (3) It encourages lazy VCS packagers (weak argument). Anatol, even though I disagree with you, it was a worthwhile suggestion. Thanks, Ido

Doug Newgard

6:41 a.m.

----------------------------------------

...

Date: Thu, 31 Oct 2013 01:32:03 -0400 From: ido@kernel.org To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Anatol, Doug,

...
...
I do not propose to remove pkgver(). What I say is that vcs version generator becomes non-trivial and many people use different and inconsistent VCS versions. It indicates that there should be some standard way to generate version. If you don't want to use the standard generator you can use your own command to generate the version.

But at least the standard generator will show how version should look like (e.g. "r" prefix or not, what delimiter should be used, etc)

If you want the "r", add it. If not, don't. I don't see the problem.

...
...
To be very blunt, if you can't figure out basic scripting enough to

write a coherent pkgver function, you don't really have any> business maintaining PKGBUILDs.

...
Please more respect, this is a public discussion.

I'm well aware that it's a public discussion, but I'm not going to sugar coat things to protect other's feelings. Bash can be complex, but basic scripting isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of the basics, you're being set up to fail from the get go.

My reading of Anatol's post does not convey any lack of understanding of the basics of shell scriptings. I think you are misreading his original post, and responding ad hominem as a result of that misunderstanding.

I can see where my comments may have come off that way, but I wasn't trying to accuse Anatol of not understanding shell scripting. My position is simply that adding a complex regex to makepkg that tries to cover as many uses as possible is folly when it could and should be done by the maintainer of the PKGBUILD where it can be targeted to the repo being used and therefor MUCH simpler.

Anatol Pomozov

6:50 a.m.

Hi On Wed, Oct 30, 2013 at 10:15 PM, Doug Newgard wrote:

...

----------------------------------------

...
Date: Wed, 30 Oct 2013 22:09:21 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard wrote:

...
----------------------------------------

...
Date: Wed, 30 Oct 2013 21:49:11 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche 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

Very, very bad idea. Every repo is different, the flexibility of the pkgver function lets the maintainer adapt to that. This was one of the major new features in pacman/makepkg 4.1.

I do not propose to remove pkgver(). What I say is that vcs version generator becomes non-trivial and many people use different and inconsistent VCS versions. It indicates that there should be some standard way to generate version. If you don't want to use the standard generator you can use your own command to generate the version.

But at least the standard generator will show how version should look like (e.g. "r" prefix or not, what delimiter should be used, etc)

If you want the "r", add it. If not, don't. I don't see the problem.

...
...
To be very blunt, if you can't figure out basic scripting enough to write a coherent pkgver function, you don't really have any> business maintaining PKGBUILDs.

Please more respect, this is a public discussion.

I'm well aware that it's a public discussion, but I'm not going to sugar coat things to protect other's feelings. Bash can be complex, but basic scripting isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of the basics, you're being set up to fail from the get go.

Dude, before doing these statements I suggest to look at your own packages. The versions of *your* packages (as well as many others) are inconsistent and this discussion tries to improve the situation. Anyway let's return to the original question about version generators. Are these "r" prefixes and the proposed "sed" good enough to make it standard?

Doug Newgard

6:55 a.m.

----------------------------------------

...

Date: Wed, 30 Oct 2013 22:50:55 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 10:15 PM, Doug Newgard wrote:

...
----------------------------------------

...
Date: Wed, 30 Oct 2013 22:09:21 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard wrote:

...
----------------------------------------

...
Date: Wed, 30 Oct 2013 21:49:11 -0700 From: anatol.pomozov@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

Hi

On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche 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

Very, very bad idea. Every repo is different, the flexibility of the pkgver function lets the maintainer adapt to that. This was one of the major new features in pacman/makepkg 4.1.

I do not propose to remove pkgver(). What I say is that vcs version generator becomes non-trivial and many people use different and inconsistent VCS versions. It indicates that there should be some standard way to generate version. If you don't want to use the standard generator you can use your own command to generate the version.

But at least the standard generator will show how version should look like (e.g. "r" prefix or not, what delimiter should be used, etc)

If you want the "r", add it. If not, don't. I don't see the problem.

...
...
To be very blunt, if you can't figure out basic scripting enough to write a coherent pkgver function, you don't really have any> business maintaining PKGBUILDs.

Please more respect, this is a public discussion.

I'm well aware that it's a public discussion, but I'm not going to sugar coat things to protect other's feelings. Bash can be complex, but basic scripting isn't difficult. If you're going to be maintain PKGBUILDs without a grasp of the basics, you're being set up to fail from the get go.

Dude, before doing these statements I suggest to look at your own packages. The versions of *your* packages (as well as many others) are inconsistent and this discussion tries to improve the situation.

Anyway let's return to the original question about version generators. Are these "r" prefixes and the proposed "sed" good enough to make it standard?

Mine are inconsistent because some need it and some don't. I don't use the "r" if it can't become an issue. I still have a few that are free-form and will get the "r" added when I update the PKGBUILD in the future. As for the sed, I would use sed -i 's/-/.r/;s/-/./g' most of the time, much easier to understand but doesn't work if the tag name has a dash.

Doug Newgard

6:57 a.m.

----------------------------------------

...

From: scimmia22@outlook.com To: aur-general@archlinux.org Date: Thu, 31 Oct 2013 00:55:06 -0500 Subject: Re: [aur-general] Revise VCS packages versioning

Mine are inconsistent because some need it and some don't. I don't use the "r" if it can't become an issue. I still have a few that are free-form and will get the "r" added when I update the PKGBUILD in the future.

As for the sed, I would use sed -i 's/-/.r/;s/-/./g' most of the time, much easier to understand but doesn't work if the tag name has a dash.

Oops, obviously the -i isn't needed here. I've been working on another script of mine and typed it out of habit. Sorry.

William Giokas

6:47 a.m.

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 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. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF

Anatol Pomozov

2:43 p.m.

Hi On Wed, Oct 30, 2013 at 10:47 PM, William Giokas <1007380@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 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.

Jerome Leclanche

4:09 p.m.

On Thu, Oct 31, 2013 at 1:43 PM, Anatol Pomozov wrote:

...

Hi

On Wed, Oct 30, 2013 at 10:47 PM, William Giokas <1007380@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 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

Anatol Pomozov

7:26 p.m.

...

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). 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?".

...

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 St. John

7:36 p.m.

On Thu, Oct 31, 2013 at 2:26 PM, Anatol Pomozov 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

William Giokas

7:37 p.m.

On Thu, Oct 31, 2013 at 11:26:27AM -0700, Anatol Pomozov 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).

This is not always true. Because of the branched, non-linear nature of git, you could have two 'version' that are the same with different SAH1s. The SHA is important in the version.

...

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?".

Yes, they will, but for bisecting where the problem is, you could really be happy for a SHA. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF

Jerome Leclanche

9:06 p.m.

On Thu, Oct 31, 2013 at 6:26 PM, Anatol Pomozov 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).

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?".

...
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

I can tell you right now a discussion on dropping the sha part of the version will be completely fruitless. They are extremely useful for bisects, devs and so on. I'd much rather spend this time talking about standardizing the version format, which is, imho, needed and you had a good proposal on. J. Leclanche

Uwe Koloska

9:17 p.m.

Hello, Am 31.10.2013 16:09, schrieb Jerome Leclanche:

...

The main issue with -git versioning is the inconsistency.

I don't think so. I think the main issue with git versioning (regarding package versions) is its non monotonic trait.

...

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.

IMHO what's really missing, are requirements, that describe what the version number has to be like *and* for what purpose! With this requirements the developer is able to craft a pkgver function that is suited for the used repository. And sure, every developer will be happy about some useful patterns like "if the repository has no tags, use '0' instead of a tag part". AFAIS there are the following requirements for version numbering: * the version number must be monotone with respect to ** newer commits ** newer package number * the version shall be "short" If there are other requirements (like "must follow semantic versioning scheme" or "must combine package and upstream version (how?)"), they should be stated clearly and with a reason. Just my 2 cents. Thank you for listening Uwe

William Giokas

9:35 p.m.

On Thu, Oct 31, 2013 at 09:17:41PM +0100, Uwe Koloska wrote:

...

Hello,

Am 31.10.2013 16:09, schrieb Jerome Leclanche:

...
The main issue with -git versioning is the inconsistency.

I don't think so. I think the main issue with git versioning (regarding package versions) is its non monotonic trait.

Thing is, there are really only two types of -git versioning: * Those with tags * Those without Each increases (or should, if the developer has any sense) as time goes forward, the only real difference is between the two, which can be easily solved by using epochs. And saying they're ugly is no damn excuse.

...

...
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.

IMHO what's really missing, are requirements, that describe what the version number has to be like *and* for what purpose! With this requirements the developer is able to craft a pkgver function that is suited for the used repository. And sure, every developer will be happy about some useful patterns like "if the repository has no tags, use '0' instead of a tag part".

Package versions only need to be comparable to those of the package, not to other packages. Epochs can be used when version styles change. It's what they were intended to be used for.

...

AFAIS there are the following requirements for version numbering: * the version number must be monotone with respect to ** newer commits ** newer package number * the version shall be "short"

If there are other requirements (like "must follow semantic versioning scheme" or "must combine package and upstream version (how?)"), they should be stated clearly and with a reason.

The pkgver should not contain any arch-specific information. If you look at the manual page, the pkgver is soleley for the upstream version, the pkgrel is for Arch releases, rebuilds or changes.

...

Just my 2 cents.

Thank you for listening Uwe

Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF

Doug Newgard

1 Nov 1 Nov

3:33 a.m.

----------------------------------------

...

Date: Thu, 31 Oct 2013 15:35:24 -0500 From: 1007380@gmail.com To: aur-general@archlinux.org Subject: Re: [aur-general] Revise VCS packages versioning

On Thu, Oct 31, 2013 at 09:17:41PM +0100, Uwe Koloska wrote:

...
Hello,

Am 31.10.2013 16:09, schrieb Jerome Leclanche:

...
The main issue with -git versioning is the inconsistency.

I don't think so. I think the main issue with git versioning (regarding package versions) is its non monotonic trait.

Thing is, there are really only two types of -git versioning:

* Those with tags * Those without

I disagree. Many of those without tags do have a version number that you can pull from somewhere, configure.ac, setup.py, etc. There is also a very common case where using the git tag will give you the wrong version number. I'll use Enlightenment as an example as I maintain the Git PKGBUILD. When version 0.17.0 was released, a tag is was created then it was branched. All of the other release tags are in this branch, 0.17.{1,2,3,4}. If you use git describe on the master branch, it will return 0.17.0 making it appear to be older than the releases from the stable branch. Really, the correct version is 0.17.99, which is what is used in the help menus, pkg-config, etc. A bit of grep is all it takes to have a correct pkgver in this case.

Jan Alexander Steffens

31 Oct 31 Oct

5:03 a.m.

On Thu, Oct 31, 2013 at 4:37 AM, Anatol Pomozov wrote:

...

Hi

I would like to discuss VCS package versioning that is described here https://wiki.archlinux.org/index.php/VCS_PKGBUILD_Guidelines

I am looking at the -git packages but it also applicable to other VCS. Here is the suggested way to create the version

local ver="$(git describe --tags)" echo "${ver//-/.}"

so 0.7-19-ge4e6e20 will turn into 0.7.19.ge4e6e20

The problem is that the revision number (19 in this case) looks like 3rd component in the version. Now imagine upstream project releases version 0.7.1. The generated version becomes 0.7.1 (and then 0.7.1.1.gfoobar). With the new tag the generated version becomes smaller (0.7.1.1 < 0.7.19). That is the real problem that I had with tup-git package - upstream uses both 2 and 3 component versions.

We should recommend a way that works this case. There is a discussion in the comments and the best recommendation is to use following recipe:

git describe | sed -E 's/([^-]*-g)/r\1/;s/-/./g'

The idea is to find the commit number and start it with "r" (revision). "r" is smaller than a number so it will help in our case.

0.7-19-ge4e6e20 => 0.7.r19.ge4e6e20

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.

I would like to suggest using "+" as separator instead of ".", so you get: 0.7+r19+ge4e6e20 0+r3000+g1a2b3c4 For added distinction from the tag version. Reads like "version 0.7 plus 19 revisions."

3822

Age (days ago)

3823

Last active (days ago)

List overview

Download

21 comments

8 participants

participants (8)

Anatol Pomozov
Doug Newgard
Ido Rosen
Jan Alexander Steffens
Jason St. John
Jerome Leclanche
Uwe Koloska
William Giokas