rhysd / go-github-selfupdate

Binary self-update mechanism for Go commands using GitHub

Home Page:https://godoc.org/github.com/rhysd/go-github-selfupdate/selfupdate

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow file name to include version information

Songmu opened this issue · comments

Even if the archive file name contains version information (e.g. cmdname_v0.0.1_linux_amd64.tar.gz), it also works now, but it is not documented and I want it to become a spec.

Many of my tools are such, and if we crossbuild using goxc or goxz with the -pv option, we actually get the archive files in which name included version information.

In other words, it is useful to include the version information in the filename when comparing version at locally, and many package system (cpan, gem, rpm etc.) file name conventions usually include version information as well.

To avoid misunderstanding, let me confirm your intention at first. The structure of release is such as:

  • v1.2.3
    • foo-bar_linux_amd64.zip
      • foo-bar_linux_amd64 (executable)
    • foo-bar_windows_amd64.exe.zip
      • foo-bar_linux_amd64.exe (executable)
    • ...
  • v1.2.2
    • ...
  • ...

Is my understanding correct?

As follows.

  • {cmd}_{version}_{goos}_{goarch}{.ext}
  • v1.2.3
    • foo-bar_v1.2.3_linux_amd64.zip
      • foo-bar (executable)
    • foo-bar_v1.2.3_windows_amd64.exe.zip
      • foo-bar.exe (executable)
    • ...
  • v1.2.2
    • ...
  • ...

Please see my releases. https://github.com/Songmu/go-sandbox/releases

For such an archive names, the go-github-selfupdate now works (unintentionally?), but I want this as a documented specification.

Ah, I understood. Thank you for clarification. The release file name containing no version (such as foo-bar_linux_amd64.zip) is intentional.

But as you showed, containing version number is also reasonable. Let me try to implement it tomorrow.

Thank you for understanding.
Since it already works, probably you only have to add the test repository under rhysd-test user, add some test code, and update the document.

Sure. I'll setup tests and confirm that it works as I intended

I confirmed that current implementation is fine. Current implementation only checks the suffix (OS and arch) of the release file name. So both foo-bar_linux_amd64.zip (without version) and foo-bar_v1.2.3_linux_amd64.zip (with version) are working.

I added a test repo to check the test case here https://github.com/rhysd-test/test-release-contain-version/releases/tag/v1.2.3.