FS#53840 - [evolution] Shows wrong version string
Attached to Project:
Arch Linux
Opened by Ralf Mardorf (Ralf) - Wednesday, 26 April 2017, 08:59 GMT
Last edited by Jan de Groot (JGC) - Saturday, 21 October 2017, 16:47 GMT
Opened by Ralf Mardorf (Ralf) - Wednesday, 26 April 2017, 08:59 GMT
Last edited by Jan de Groot (JGC) - Saturday, 21 October 2017, 16:47 GMT
|
Details
Hi,
several Arch users experience issues with Evolution. I don't, so I can't report those bugs. However, when those users sent requests to the Evolution mailing list, I noticed that they reported the wrong version. I don't know why not the official releases from upstream are packaged, however, if you package commits from git, then build with -DVERSION_SUBSTRING="+gitXXXXXX" \ -DVERSION_COMMENT="+gitXXXXXX" , without doing so "evolution -v" does show another version then actually was build and packaged. From the mailing list: "[snip] the detailed Arch versions are shown below. Maybe those commits are ok, however, at least the Arch versions aren't simply [rocketmouse@archlinux ~]$ evolution -v evolution 3.24.2 they are 3.24.1+git: [rocketmouse@archlinux ~]$ grep _commit /var/abs/extra/evolution/PKGBUILD _commit=fc6d11eb4aab2cb44a6f63ea540d14138d278605 # gnome-3-24 [snip]" - https://mail.gnome.org/archives/evolution-list/2017-April/msg00120.html "[snip] You surely do not have 3.24.2, that had not been released yet. The way the Arch maintainer does his/her duty leads only to confusion for users and nothing else. It's a very wrong approach, from my point of view. The packager should use -DVERSION_SUBSTRING="+gitXXXXXX", eventually -DVERSION_COMMENT="+gitXXXXXX", (though none of this is shown in Help->About (I'm changing it for the next release), only in `evolution --version`) during the build (pass to cmake command) and skip the commit where the version is bumped just after the previous release, then everything will make sense and not be confusing. [snip]" - https://mail.gnome.org/archives/evolution-list/2017-April/msg00128.html Steps to reproduce: [rocketmouse@archlinux ~]$ pacman -Si evolution{,-ews,-data-server,-bogofilter,-spamassassin}|grep Ve Version : 3.24.1+6+gfc6d11eb4a-1 Version : 3.24.1-1 Version : 3.24.1+5+g98589a27b-2 Version : 3.24.1+6+gfc6d11eb4a-1 Version : 3.24.1+6+gfc6d11eb4a-1 [rocketmouse@archlinux ~]$ evolution -v evolution 3.24.2 Regards, Ralf |
This task depends upon
Closed by Jan de Groot (JGC)
Saturday, 21 October 2017, 16:47 GMT
Reason for closing: Won't implement
Additional comments about closing: See last comment.
Saturday, 21 October 2017, 16:47 GMT
Reason for closing: Won't implement
Additional comments about closing: See last comment.
If upstream cares about versions in evolution -v output, then upstream should not commit "Post-release version bump" but do that on release.
We build from git because of 2 main reasons:
- easier to add upstream committed patches
- release tarballs are often generated with broken tools
actually it were _several_ Arch users who sent requests, providing wrong version information. I posted to the mailing list only to correct the version information. What other distros might do is irrelevant for us. It's also unimportant if upstream decides to default to 3.24.1 or 3.24.2, if you compile and package 3.24.1gitabcd. In my experiences, based on following the Evolution mailing list, official releases from upstream are sometimes buggy, but not more or less often, than for the majority of any other software, so IMO there's no reason to divert from the Arch policy. However, if you feel the need to build from git, I don't understand why you won't build with -DVERSION_SUBSTRING="+gitXXXXXX" -DVERSION_COMMENT="+gitXXXXXX".
Anyway, I only wanted to inform you about an issue that arise on the Evolution mailing list, feel free to ignore it.
Regards,
Ralf
"[snip]
Hi,
okay, that sounds better. Let him use just one of those, better might
be -DVERSION_SUBSTRING="gitXXXXX", which will generate "X.Y.ZgitXXXXX".
I understand that it's a pita to hunt for "Post-release version bump"
commits, but it also makes sense to bump the version after release,
thus it's clear that this version is not 'the previous version'. Or I
just got use to this approach during the years. Each approach has its
pros and cons.
Thanks and bye,
Milan" - https://mail.gnome.org/archives/evolution-list/2017-April/msg00141.html
They don't expect downstream packagers or other people building the software to work around the fact that their source code is telling a blatant lie.