On Wed, Jan 16, 2013 at 4:17 PM, Ryan Schmidt <[email protected]> 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. _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-dev
