Opened 13 years ago
Closed 9 years ago
#33889 closed enhancement (fixed)
github-1.0: add rss-type of livecheck for commit hashes diretly sent to the group
| Reported by: | seanfarley (Sean Farley) | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.0.4 |
| Keywords: | github-1.0 | Cc: | ryandesign (Ryan Carsten Schmidt), cooljeanius (Eric Gallager) |
| 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 (2)
Change History (8)
Changed 13 years ago by seanfarley (Sean Farley)
| Attachment: | github-rss.patch added |
|---|
Changed 13 years ago by seanfarley (Sean Farley)
| Attachment: | github-whitespace.patch added |
|---|
comment:1 follow-up: 2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign@… added |
|---|
comment:2 Changed 13 years ago by seanfarley (Sean 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:5 Changed 9 years ago by larryv (Lawrence Velázquez)
| Component: | base → ports |
|---|
comment:6 Changed 9 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
This type of change was committed in r102489.
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.