Created attachment 194875 [details]
[PATCH] sysutils/intel-pcm-devel: update to '20180620' (7f211c9)
PORTEPOCH was used!
once the previous version was using 'g' as prefix and portscout would always announce old versions (e.g., 201703) as newer ones this bump is needed.
(In reply to Vinícius Zavam from comment #0)
So adding PORTEPOCH should make the "g" prefixed version newer and mean you don't need to remove the "g" from the DISTVERSION, I think. (But the patch removes it.) Can we leave it instead? It's what should be there, AFAIK.
(In reply to Steve Wills from comment #1)
my concern is getting future "SPAM" from the portscout tagging this port as outdated and pointing the stable version as newer than its -devel variant (right now it is tagged as outdated).
sysutils/intel-pcm's version is 201710, and does not prefixes it with 'g'. I suggested to take off the prefix and stick with the upstream version standard.
the 'g' prefix is there only because I did get the felling people really use it for *every* port that gets its distfiles from GitHub, but some don't even prefix their versions with 'g'; a few actually are using 'd' (really confuse).
sounds okay to proceed or do you think we can have more eyes on it?
very appreciated for your feedback Steve. many thanks!
(In reply to Vinícius Zavam from comment #2)
See example 5.13 here:
which says we need to keep the "g".
Also, if you keep the g and add the PORTEPOCH, then compare the versions via "pkg version", you see:
$ pkg version -t g20180319 g20180620,1
which I think shows that it's doing what we want. And I believe portscout should work the same and if it doesn't then we can report a bug in portscout.
(In reply to Steve Wills from comment #3)
Looking at this further, I'm not even sure you should need the PORTEPOCH:
$ pkg version -t g20180319 g20180620
(In reply to Steve Wills from comment #4)
cool! thanks for clarifying a bit more about the 'g' prefix; I saw other ports (like devel/llvm-devel) that use different standards and that got me a bit confuse, but that is maybe some particular case and does not address us here. anyway, many thanks! appreciated.
so... did you check the portscout for sysutils/intel-pcm-devel? my concern is still that it points sysutils/intel-pcm's version as newer than sysutils/intel-pcm-devel's even if -devel is newer. https://firstname.lastname@example.org
sysutils/intel-pcm uses the official release/tag versioning system from GH, but -devel don't. how could I work to make portscout happy?
again, thanks for your concern!
(In reply to Vinícius Zavam from comment #5)
You could add the PORTEPOCH:
$ pkg version -t 201710 g20180319
$ pkg version -t 201710 g20180319,1
But, is portscout ever going to be useful for this port? I don't think it can be right now, so perhaps you want to just disable it for this port:
Created attachment 194913 [details]
[PATCH] sysutils/intel-pcm-devel: update to '20180620' (7f211c9), PORTSCOUNT ignored
based on recommendations and ideas from swills@, I am disabling PORTSCOUT for this port because it stable version would always be reported as newer than this -devel version of the port.
thank you swills.
Created attachment 194914 [details]
[LOG/11amd64] sysutils/intel-pcm-devel: update to '20180620' (7f211c9), PORTSCOUNT ignored
Poudriere Log, 11amd64
(In reply to Vinícius Zavam from comment #7)
For the record, the reason I said portscout wouldn't be useful here isn't because the stable version is newer (it's not), but because portscout has no way of recognizing new versions of the devel version as far as I know.
Regardless of the reason, these changes look correct, I'll go ahead with them, thanks.
(In reply to Steve Wills from comment #9)
Sorry, I misread what you said. Anyway, the point I wanted to make was that we can make the devel version newer by adding the PORTEPOCH but even then portscout will not be able to find a newer devel version, so you might as well set it to ignore and save portscout a (tiny) bit of time.
A commit references this bug:
Date: Fri Jul 6 14:45:48 UTC 2018
New revision: 474013
sysutils/intel-pcm-devel: update to 20180620
Submitted by: Vin?cius Zavam <email@example.com> (maintainer)