For stability and to avoid rebuilding images with each commit, I usually make Binder URLs that point to the latest release/tag of my repo, rather than master. The trouble is, I have to keep updating that URL. It would be great if there was a single URL pattern that always matches "latest release".
If the dates of tags are not available for some reason (for determining which one is "latest"), then perhaps the last in semantic version order? My release/tag names are all unadorned semantic versions (i.e. no project name, not even a "v" before the three numbers, separated by dots). A particularly slick implementation would support semantic version inequalities, like ">=1.2.3" to mean "1.2.3 or later, but not prereleases like 1.3.0rc1".
This would benefit a common use-case of Binder for demonstrating software, where you want a permanent link to the latest stable version. Documentation usually has this, with a "latest" or "stable" tag in the URL pattern to go to the latest version of the documentation鈥攊t would be great if Binder had the same thing.
You can get the list of tags in reverse order of creation from the GitHub API e.g. https://api.github.com/repos/IDR/idr-notebooks/tags so the information is available.
Alternatively you could solve the problem now by creating your own GitHub branch, e.g. latest, and keeping that in sync with the latest tag. This avoids problems where you're maintaining multiple incompatible releases (e.g. 1.x, 2.x) so most recently created tag might not be the the latest version, or dealing with a myriad of versioning systems.
Alternatively you could solve the problem now by creating your own GitHub branch, e.g. latest, and keeping that in sync with the latest tag.
Oh, that's right. Thanks for the suggestion! (I'll think about how to automate a latest branch in CI...)
Several people also use a latest tag that they move as they make new releases/updates and use that in the mybinder.org link.
If you find a way that works for you it might be worth adding this as a FAQ entry for people from the future.
Don't you have to delete and recreate a tag to move it? I would have thought that branches are easier to maintain for that reason. (And "easy" only if they're going forward鈥擨'm not sure what surgery is required if latest needs to roll back changes.)
Anyway, this is getting more into git than Binder. It would be nice to see this as part of a "best practices" suggestion (or maybe I missed it). One thing that could still be a useful Binder feature would be selecting based on a semantic version rule (e.g. ">=1.2.3") but this is a casual wish, since I could go and try to implement the latest branch myself for the most common functionality.
Hi @jpivarski, how did you end up solving this?
I didn't. Whenever I use Binder, I manually set the URL tag to the latest tag, even if that means swimming it to a year that doesn't exist yet (in order for the tagged release to contain eventually-correct URLs).