New Ticket     Tickets     Wiki     Browse Source     Timeline     Roadmap     Ticket Reports     Search

Ticket #33889 (new enhancement)

Opened 14 months ago

Last modified 4 months ago

github-1.0: add rss-type of livecheck for commit hashes diretly sent to the group

Reported by: sean.michael.farley@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 2.0.4
Keywords: github-1.0 Cc: ryandesign@…, egall@…
Port:

Description

This adds a neat automatic check of the rss feed (using regexm) only in the event that a commit hash is used as the ${github.version}. Also attached is a patch for whitespace, if that matters to anyone else.

Attachments

github-rss.patch (1.4 KB) - added by sean.michael.farley@… 14 months ago.
github-whitespace.patch (3.8 KB) - added by sean.michael.farley@… 14 months ago.

Change History

Changed 14 months ago by sean.michael.farley@…

Changed 14 months ago by sean.michael.farley@…

comment:1 follow-up: ↓ 2 Changed 14 months ago by ryandesign@…

  • Cc ryandesign@… added

The situation shouldn't ever arise that github.version would be set to a git hash. Using a hash as a version number is problematic because it does not necessarily numerically increase, which means the port author would have to increase the epoch with many updates. github.version should be the dotted-decimal-formatted version number of the software, or if none exists, then some other number that generally increases, such as a date string (see for example the VillainousStyle port).

But I am pleased that there is a way to check the github commit log by RSS. Rather than decide whether to do this based on the length of the version, we should perhaps check whether fetch.type is git and git.branch is a valid hash (note: git hashes don't have to be 40 characters; they could be abbreviated). We then have two choices: we could set livecheck.version to git.branch and pull the new latest git hash out of the RSS feed and display those in the livecheck. Or we could assume that the version number is a date string and pull the date of the latest commit out of the RSS feed and display those in the livecheck.

comment:2 in reply to: ↑ 1 Changed 14 months ago by sean.michael.farley@…

Replying to ryandesign@…:

The situation shouldn't ever arise that github.version would be set to a git hash. Using a hash as a version number is problematic because it does not necessarily numerically increase, which means the port author would have to increase the epoch with many updates. github.version should be the dotted-decimal-formatted version number of the software, or if none exists, then some other number that generally increases, such as a date string (see for example the VillainousStyle port).

How then would a port work with a package that isn't versioned properly or even more common: a package that has new fixes? I've been doing things like:

github.setup  seanfarley bout-dev ce7933607dd92bf4ed01d715b531afddc909bd0a
version       1.1a1

But I am pleased that there is a way to check the github commit log by RSS. Rather than decide whether to do this based on the length of the version, we should perhaps check whether fetch.type is git and git.branch is a valid hash (note: git hashes don't have to be 40 characters; they could be abbreviated). We then have two choices: we could set livecheck.version to git.branch and pull the new latest git hash out of the RSS feed and display those in the livecheck. Or we could assume that the version number is a date string and pull the date of the latest commit out of the RSS feed and display those in the livecheck.

But this would break the ability to just download the newest commit using a tarball instead of a full git clone (which could take much, much longer). Maybe set a new option?

github.livecheck rss
github.livecheck_version ce7933607dd92bf4ed01d715b531afddc909bd0a

comment:3 Changed 14 months ago by sean.michael.farley@…

No response?

comment:4 Changed 4 months ago by egall@…

  • Cc egall@… added

Cc Me!

Note: See TracTickets for help on using tickets.