Hi On Sun, May 12, 2013 at 8:07 AM, Ross Lagerwall <rosslagerwall@xxxxxxxxx> wrote: > > On Sat, May 11, 2013 at 11:26:19AM -0700, Anatol Pomozov wrote: > > There are some fals positive and negative results though, mostly because > > download servers return different sort of weird responses. I still work on > > work-arounds for all these cases. > > > > Have you any ideas how to avoid showing development releases as new > releases? For example, Perl 5.17 shows as a new release but AFAIK it is > only a development release... Currently pkgoutofdate does not have such functionality. Different projects have different release strategies. Some projects use -betaXXX for development releases, some use odd minor numbers in version. These information is project specific and should be stored in PKGBUILD. I proposed a solution in the FS#34447 [1]. The idea is that in case if a project has specific release cycle then PKGBUILD will contain additional function, let's say "released_version()", this function should provide pkgoutofdate "recommended version". For example for project "less" http://www.greenwoodsoftware.com/less/ the function will go to homepage, fetch its text, parse for ancor word and get the version: released_version() { curl -s http://www.greenwoodsoftware.com/less/ | grep -Po "The current released version is less-(\d+)" | grep -Po "\d+" } This function returns number from homepage (currently 458). The number compared with version in PKGBUILD and it is smaller (or just different) then package considered out of date. This solution is somewhat similar to macport's livecheck implementation [2]. As I said this requires only for minority of projects. Most projects are just fine with "the next version" algorithm described in the first message. https://bugs.archlinux.org/task/34447 http://guide.macports.org/chunked/reference.livecheck.html
