New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow file name to include version information #5

Closed
Songmu opened this Issue Jan 2, 2018 · 7 comments

Comments

Projects
None yet
2 participants
@Songmu
Contributor

Songmu commented Jan 2, 2018

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.

@rhysd

This comment has been minimized.

Show comment
Hide comment
@rhysd

rhysd Jan 2, 2018

Owner

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?

Owner

rhysd commented Jan 2, 2018

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?

@rhysd rhysd added the enhancement label Jan 2, 2018

@Songmu

This comment has been minimized.

Show comment
Hide comment
@Songmu

Songmu Jan 2, 2018

Contributor

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
    • ...
  • ...
Contributor

Songmu commented Jan 2, 2018

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
    • ...
  • ...
@Songmu

This comment has been minimized.

Show comment
Hide comment
@Songmu

Songmu Jan 2, 2018

Contributor

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.

Contributor

Songmu commented Jan 2, 2018

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.

@rhysd

This comment has been minimized.

Show comment
Hide comment
@rhysd

rhysd Jan 2, 2018

Owner

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.

Owner

rhysd commented Jan 2, 2018

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.

@Songmu

This comment has been minimized.

Show comment
Hide comment
@Songmu

Songmu Jan 2, 2018

Contributor

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.

Contributor

Songmu commented Jan 2, 2018

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.

@rhysd

This comment has been minimized.

Show comment
Hide comment
@rhysd

rhysd Jan 2, 2018

Owner

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

Owner

rhysd commented Jan 2, 2018

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

@rhysd rhysd closed this in 8817d53 Jan 3, 2018

@rhysd

This comment has been minimized.

Show comment
Hide comment
@rhysd

rhysd Jan 3, 2018

Owner

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.

Owner

rhysd commented Jan 3, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment