Github Group

[Sean Farley]

On Wed, Jan 16, 2013 at 4:17 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>
> 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.

No worries. I forget lots of things until I want to clear my plate of
todo items (which I'm trying to do now) :-)

> 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

Righto. In the time since opening this ticket, I've learned more about
versioning in macports as well.

>> 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 problem with this is that some sites (bitbucket) only specify 12
characters. I believe 12 is enough to provide uniques prefixes for a
SHA1 hash for up to 16^12 commits. My gut reaction is to go for 12 but
I don't feel strongly one way or the either.

> 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.

Then how would be test the if-statement to determine checking the rss
feed or scrapping the tags page?

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

Oh. Are you suggesting that we always use the committish? Or do you
mean that the check should only be len(github.version) > 8 && regex
^[0-9a-f]+$ matches?

> 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.

Alas.