Github Group

[Ryan Schmidt]

On Jan 16, 2013, at 14:17, Sean Farley wrote:

> I wanted to revisit and close this ticket I started almost a year ago:
> 
> https://trac.macports.org/ticket/33889

Sorry I forgot about this ticket.

I'm not sure I agree anymore with what I wrote in that ticket 10 months ago. The purpose of the github.setup line is to specify values that are used to retrieve the software from github. Therefore I now think that the third argument to github.setup should either be the version number from the github tag or the github committish; in the latter case, the version should then be overridden as you suggest; usually, since there won't be a specific version number associated with a random github commit, I advocate setting version to a date string of that commit, appended to a relevant version number, if known. So for example:

github.setup seanfarley BOUT d97c056fa59c577eef3e7edd230fca03413f1fdf
version 20111118

or if this is, say, a development version around version 1.0, then:

version 1.0-20111118


> I think it'll suffice to check for a tarball download + an empty tag
> prefix + len(version) > 12. A hash can be looked up at any length as
> long as it's match is unique, therefore the length of 12 is a soft
> requirement. I didn't pull it out of thin air, though; it's from an
> early version of git / mercurial of making 12 a lower bound until
> better algorithms arose.

I believe the committish should always be specified in full, with all 40 characters, to prevent overlap with possible future commits.

The check should not include an empty tag prefix; there's no reason why you couldn't have a tag prefix, to check if and when a future stable version is tagged.

The check on github.version should include the regex ^[0-9a-f]+$

I'm undecided on how or whether the length of github.version should be considered. I suppose at the very least we should verify the length is greater than 8 characters, so that version numbers that look like YYYYMMDD dates are not considered.



On Jan 16, 2013, at 15:04, Sean Farley wrote:

> Alternatively, we could just check the rss feed if there's no match on
> the tags page. Is there an easy way to have a failover for livechecks?
> Searching through other portfiles seems to indicate 'no'.

There is no fallback for the livecheck. The specified URL and regex either works or it doesn't.