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.
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 anatol.pomozov@gmail.com 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.
Hi
On Wed, Oct 30, 2013 at 8:51 PM, Jerome Leclanche adys.wh@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 like this proposal a lot. J. Leclanche
On Thu, Oct 31, 2013 at 3:37 AM, Anatol Pomozov anatol.pomozov@gmail.com 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.
----------------------------------------
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 adys.wh@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
- Find what VCS is used
- 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.
Hi
On Wed, Oct 30, 2013 at 9:53 PM, Doug Newgard scimmia22@outlook.com 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 adys.wh@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
- Find what VCS is used
- 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.
----------------------------------------
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 scimmia22@outlook.com 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 adys.wh@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
- Find what VCS is used
- 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.
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
----------------------------------------
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.
Hi
On Wed, Oct 30, 2013 at 10:15 PM, Doug Newgard scimmia22@outlook.com 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 scimmia22@outlook.com 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 adys.wh@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
- Find what VCS is used
- 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?
----------------------------------------
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 scimmia22@outlook.com 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 scimmia22@outlook.com 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 adys.wh@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
- Find what VCS is used
- 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.
----------------------------------------
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.
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@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
- Find what VCS is used
- 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,
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 adys.wh@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
- Find what VCS is used
- 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).
--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.
On Thu, Oct 31, 2013 at 1:43 PM, Anatol Pomozov anatol.pomozov@gmail.com 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 adys.wh@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
- Find what VCS is used
- 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).
--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:
- 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.
- 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
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
On Thu, Oct 31, 2013 at 2:26 PM, Anatol Pomozov anatol.pomozov@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
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,
On Thu, Oct 31, 2013 at 6:26 PM, Anatol Pomozov anatol.pomozov@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).
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
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
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,
----------------------------------------
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.
On Thu, Oct 31, 2013 at 4:37 AM, Anatol Pomozov anatol.pomozov@gmail.com 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."
aur-general@lists.archlinux.org