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. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
