On Wed, Sep 15 2021, iskarian@mgsn.dev wrote: > Hi, > > September 10, 2021 9:21 AM, "Xinglu Chen" wrote: > >> * guix/git.scm (ls-remote-refs): New procedure. >> * tests/git.scm ("remote-refs" "remote-refs: only tags"): New tests. >> * guix/import/git.scm: New file. >> * doc/guix.texi (Invoking guix refresh): Document it. >> * tests/import-git.scm: New test file. >> * Makefile.am (MODULES, SCM_TESTS): Register the new files. >> >> Co-authored-by: Sarah Morgensen > > Overall this is looking good. Thank you for adding tests (for > remote-refs as well!), much appreciated. It looks like you've done > some good polishing. I see a few nits, which I'll point out in a > separate email when I'm not on mobile. I'll also give it a good test. > > But... I've been thinking about the overall approach for a couple > days, because I'm not very happy with the complexity of my heuristic. > > There can be a lot of weird tags in a repository--look at the one for > xf86-video-intel for example. My heuristic attempts to capture the > assumption that repostories tend to move from using "_" or "-" to "." > but it does fail to account for moving to or from dates (because dates > don't compare with normal versions). But if a repo moved from using versions to tags, or vice-versa, we still wouldn’t know if say “3.0.1” is newer than “2021.03.02”. We would have to know when the “3.0.1” tag was created. Maybe we could have a ‘release-tag-date-scheme?’ property, that way we could just try to match dates? > I also realized that we are not using a very useful piece of > information--the previous version/tag combo. I expect that in the > vast majority of cases, the version delimiter for the newest version > will be the same as the version delimiter for the last known version. > (Perhaps the prefix as well?) Can we use this information to make our > guesses better? What do you think? That sounds like a good idea. What should happen if the delimiter from the previous version/tag combo is different from the one that the ‘guess-delimiter’ procedure returns? Should the one from the previous version/tag combo take precedence. > Despite saying all that, it's probably better to not try to get it > perfect on the first go--we can always adjust the internals later. We > just want to avoid showing bogus updates. Yeah, we can always improve things later. > (Later, I think I'll put together a dataset of tags and current > versions to see if I can test how well a particular algorithm works.) Cool, looking forward to that. :-)