Release tarballs are named ambiguously #700
Comments
|
As discussed in #757 and #731, the linux instructions can now (arguably) be shortened to a single command ( |
|
@ekingery thank you. As we mentioned in #757 (and also alluded to in exercism/exercism#3765) we cannot instruct people to rely on a method of distribution that is not in our control, and we currently don't intend to use multiple distribution methods, because we struggle enough at the moment to maintain the ones that we use. |
|
No problem @kytrinyx, thanks for your work on this project, it is terrific! For the record, I didn't actually publish the snap, it was @ric2b. By "not in our control", you mean that a member of the exercism team didn't publish it? In that case I imagine @ric2b would be glad to hand off the exercism name of the snap. I assume he created it independently because in #757 the OP offered to create and commit a snapcraft.yml file but gave up after what seems to be some misguided resistance. I can see why you struggle with the maintenance of your current linux .tgz distribution method (which is currently broken in my experience). This is one reason why I think it is worth considering scrapping it and supporting snap instead. It would simplify the install instructions / walk-through to basically be the same as the homebrew install on OSX. The existing build script could remain the same. I will volunteer to watch for new releases and push new versions to homebrew and snap if that is helpful. I could also update the to-be-committed snapcraft.yml file to support the various architectures currently supported by exercism. The packaging could eventually be automated into a CI build, although that is likely beyond the time I would have to volunteer. I realize that snap doesn't have the ubiquity of homebrew, but it's getting there and seems to be the best option short of providing multiple distribution methods (.rpm, .deb, etc). The slack desktop client and github desktop client both support snap as a primary distribution / installation method on linux. If you are not familiar with this process at Github, perhaps you could ask the advice of someone who works on the distribution of the desktop client? Snap strikes me as a good single-distribution method given it requires minimal maintenance, has a simple installation path for users, and has a relatively large reach / install base. Lastly, I noticed that homebrew is supported on linux too. As a linux user it's not something I would advocate for, but it could be another option for getting out of the "beginner programmer needs to know their computer architecture in order to install exercism" business. I hope this is helpful in thinking about your current installation issues. Obviously it's your call and I respect whichever direction you choose. |
Yes. We had that happen previously with another package that someone else maintained. I wasn't able to publish the homebrew package the last time I cut a release, due to an incompatibility between my development environment and the homebrew environment that took more than one hour to debug (I have to timebox this sort of thing). Indeed, it took me nearly a year to cut a new release of the CLI because I was dreading the process, because homebrew always throws me curveballs, and the maintainers believe very strongly that if you're a developer you shouldn't need help figuring curveballs out.
That was my original concern, yes. That said, if it's "mostly common", then I don't mind saying "use this, or I'll assume you know how to unpack a tarball".
Yeah, but most people don't use it, so I wouldn't want Exercism to recommend it.
That is something that I have had on my TODO list for like four years :-)
That would be fantastic. Would you also join us on the Slack where we have mentors and maintainers chat? I would like to make an exercism/cli-packaging team or something of which you and I would be the sole members for now, but if we added a few more folks and made sure we could script up as much as possible and document as much as possible, then this would feel a lot less fragile and stressful! |
Of course! And I can also help if needed. This would be super easy to script, it's already just one command for building the package and another command to publish it. But let me warn you that Linux being Linux already has 2 competing projects to do desktop application sandboxing and distribution: Snap (by Ubuntu/Canonical) and Flatpak (By RedHat). Both Snap and Flatpak can be installed on any distro so even RedHat based distro's can use Snap, it's just not pre-installed. |
|
I've already done some automatic deployment to the AUR (arch Linux user repository) which requires knowledge of some SSH private key on the CI system. On gitlab I where I did that, I know what and where to tweak to lower the risk of leakage. Examples are protecting the injected environment variables that it's only available on certain branches and tags, but does Travis have something like that? If not, an aggressor could easily get the private keys/tokens necessary for the deployment by just doing a PR and an I've heard circle where able to do similar secret management than gitlab ci, but circle doesn't support Mac os AFAIK, also I'm not sure about it's limits/quotas. Anyway, I'd be happy to join any CI/CD task force that might be created, as this is really what I like to do, automate things... (Also GitHub actions might be helpful after all what I've read so far, but I'm not sure whether or not exercism organisation is suitable to join the beta, or if @kytrinyx could otherwise push them to the org) |
Absolutely - I joined the Exercism Team slack (@ekingery) and I'd be glad to follow up there. I can't create channels so I'll wait for an invite. Making the process less fragile and stressful sounds great to me and I think we have a path and a good set of people to help. |
|
Ok, this is all awesome. I will get the team and channel and everything sorted out. @ric2b are you in that slack by any chance? If not, once I get the team set up I'll get you added to the slack as well. |
|
I'm not in the slack, no. |
|
@ric2b Would you email me at [email protected] if you want into the Slack? (It's certainly not a requirement). |
|
@ric2b, could you transfer the exercism snap name to the account named |
|
One more ping for @ric2b, are you available to help transfer the snapcraft / ubuntu one ownership of the |
|
Sorry, I changed to a new job and have been focusing on that. I'll PM you. |
|
We are planning to use GoReleaser to help package and distribute the CLI. Below are the proposed names for the new packages (with
|
Before this commit, the release assets were named like:
configlet-linux-64bit.tgz
configlet-mac-64bit.tgz
configlet-windows-64bit.zip
configlet_4.0.0-beta.7_checksums_sha256.txt
With this commit, the next release will have assets named:
configlet_4.0.0-beta.8_checksums_sha256.txt
configlet_4.0.0-beta.8_linux_x86-64.tar.gz
configlet_4.0.0-beta.8_macos_x86-64.tar.gz
configlet_4.0.0-beta.8_windows_x86-64.zip
Where we:
- Make the archive naming format match that of the checksums file
- Add a version string
- Delimit with an underscore, not a hyphen
- Rename `64bit` to `x86-64`
- Rename `32bit` to `i386`
- Rename `tgz` to `tar.gz`
- Rename `mac` to `macos`
So far, we have only released configlet for x86-64, and the release
assets have always had an ambiguous `64bit` in the names. This naming
format was old (added by d4c6e26, 2020-10-09), and was ultimately
inherited from:
- the `exercism/configlet-v2` releases [1]
- the `exercism/cli` releases [2][3]
However, we're getting closer to adding releases for other 64-bit
architectures, so it's especially important to change the names now.
The rationale for the particular use of underscores and hyphens is:
- We want to have the version string in the asset filenames
- Configlet uses version strings that are compatible with the Semantic
Versioning spec
- It is more common to use hyphens in executable names than
underscores
- The Semantic Versioning spec forbids using an underscore, and
specifies that prerelease versions can use hyphens [4]:
Section 9:
A pre-release version MAY be denoted by appending a hyphen and a
series of dot separated identifiers immediately following the patch
version. Identifiers MUST comprise only ASCII alphanumerics and
hyphens [0-9A-Za-z-].
[...]
Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
That is, there's an argument for the format of:
some-app_1.0.0-beta.1_linux_x86-64.tar.gz
rather than:
some_app-1.0.0-beta.1-linux-x86_64.tar.gz
because `_` fully separates the components of the first, and `-` does
not separate the components of the second (due to the `-beta` part of
the version string). This does ignore the convention of `_` as an
inter-word space, however.
[1] https://github.com/exercism/v2-configlet/releases
[2] exercism/cli#700 (comment)
[3] https://github.com/exercism/cli/releases/tag/v3.0.12
[4] https://semver.org/
Closes: #363
Refs: #24
Before this commit, the release assets were named like:
configlet-linux-64bit.tgz
configlet-mac-64bit.tgz
configlet-windows-64bit.zip
configlet_4.0.0-beta.7_checksums_sha256.txt
With this commit, the next release will have assets named:
configlet_4.0.0-beta.8_checksums_sha256.txt
configlet_4.0.0-beta.8_linux_x86-64.tar.gz
configlet_4.0.0-beta.8_macos_x86-64.tar.gz
configlet_4.0.0-beta.8_windows_x86-64.zip
Where we:
- Make the archive naming format match that of the checksums file
- Add a version string
- Delimit with an underscore, not a hyphen
- Rename `64bit` to `x86-64`
- Rename `32bit` to `i386`
- Rename `tgz` to `tar.gz`
- Rename `mac` to `macos`
So far, we have only released configlet for x86-64, and the release
assets have always had an ambiguous `64bit` in the names. This naming
format was old (added by d4c6e26836a5, 2020-10-09), and was ultimately
inherited from:
- the `exercism/configlet-v2` releases [1]
- the `exercism/cli` releases [2][3]
However, we're getting closer to adding releases for other 64-bit
architectures, so it's especially important to change the names now.
The rationale for the particular use of underscores and hyphens is:
- We want to have the version string in the asset filenames
- Configlet uses version strings that are compatible with the Semantic
Versioning spec
- It is more common to use hyphens in executable names than
underscores
- The Semantic Versioning spec forbids using an underscore, and
specifies that prerelease versions can use hyphens [4]:
Section 9:
A pre-release version MAY be denoted by appending a hyphen and a
series of dot separated identifiers immediately following the patch
version. Identifiers MUST comprise only ASCII alphanumerics and
hyphens [0-9A-Za-z-].
[...]
Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
That is, there's an argument for the format of:
some-app_1.0.0-beta.1_linux_x86-64.tar.gz
rather than:
some_app-1.0.0-beta.1-linux-x86_64.tar.gz
because `_` fully separates the components of the first, and `-` does
not separate the components of the second (due to the `-beta` part of
the version string). This does ignore the convention of `_` as an
inter-word space, however.
[1] https://github.com/exercism/v2-configlet/releases
[2] exercism/cli#700 (comment)
[3] https://github.com/exercism/cli/releases/tag/v3.0.12
[4] https://semver.org/
Closes: exercism/configlet#363
Refs: exercism/configlet#24
exercism/configlet#705
Before this commit, the release assets were named like:
configlet-linux-64bit.tgz
configlet-mac-64bit.tgz
configlet-windows-64bit.zip
configlet_4.0.0-beta.7_checksums_sha256.txt
With this commit, the next release will have assets named:
configlet_4.0.0-beta.8_checksums_sha256.txt
configlet_4.0.0-beta.8_linux_x86-64.tar.gz
configlet_4.0.0-beta.8_macos_x86-64.tar.gz
configlet_4.0.0-beta.8_windows_x86-64.zip
Where we:
- Make the archive naming format match that of the checksums file
- Add a version string
- Delimit with an underscore, not a hyphen
- Rename `64bit` to `x86-64`
- Rename `32bit` to `i386`
- Rename `tgz` to `tar.gz`
- Rename `mac` to `macos`
So far, we have only released configlet for x86-64, and the release
assets have always had an ambiguous `64bit` in the names. This naming
format was old (added by d4c6e26836a5, 2020-10-09), and was ultimately
inherited from:
- the `exercism/configlet-v2` releases [1]
- the `exercism/cli` releases [2][3]
However, we're getting closer to adding releases for other 64-bit
architectures, so it's especially important to change the names now.
The rationale for the particular use of underscores and hyphens is:
- We want to have the version string in the asset filenames
- Configlet uses version strings that are compatible with the Semantic
Versioning spec
- It is more common to use hyphens in executable names than
underscores
- The Semantic Versioning spec forbids using an underscore, and
specifies that prerelease versions can use hyphens [4]:
Section 9:
A pre-release version MAY be denoted by appending a hyphen and a
series of dot separated identifiers immediately following the patch
version. Identifiers MUST comprise only ASCII alphanumerics and
hyphens [0-9A-Za-z-].
[...]
Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
That is, there's an argument for the format of:
some-app_1.0.0-beta.1_linux_x86-64.tar.gz
rather than:
some_app-1.0.0-beta.1-linux-x86_64.tar.gz
because `_` fully separates the components of the first, and `-` does
not separate the components of the second (due to the `-beta` part of
the version string). This does ignore the convention of `_` as an
inter-word space, however.
[1] https://github.com/exercism/v2-configlet/releases
[2] exercism/cli#700 (comment)
[3] https://github.com/exercism/cli/releases/tag/v3.0.12
[4] https://semver.org/
Closes: exercism/configlet#363
Refs: exercism/configlet#24
exercism/configlet#705
Before this commit, the release assets were named like:
configlet-linux-64bit.tgz
configlet-mac-64bit.tgz
configlet-windows-64bit.zip
configlet_4.0.0-beta.7_checksums_sha256.txt
With this commit, the next release will have assets named:
configlet_4.0.0-beta.8_checksums_sha256.txt
configlet_4.0.0-beta.8_linux_x86-64.tar.gz
configlet_4.0.0-beta.8_macos_x86-64.tar.gz
configlet_4.0.0-beta.8_windows_x86-64.zip
Where we:
- Make the archive naming format match that of the checksums file
- Add a version string
- Delimit with an underscore, not a hyphen
- Rename `64bit` to `x86-64`
- Rename `32bit` to `i386`
- Rename `tgz` to `tar.gz`
- Rename `mac` to `macos`
So far, we have only released configlet for x86-64, and the release
assets have always had an ambiguous `64bit` in the names. This naming
format was old (added by d4c6e26836a5, 2020-10-09), and was ultimately
inherited from:
- the `exercism/configlet-v2` releases [1]
- the `exercism/cli` releases [2][3]
However, we're getting closer to adding releases for other 64-bit
architectures, so it's especially important to change the names now.
The rationale for the particular use of underscores and hyphens is:
- We want to have the version string in the asset filenames
- Configlet uses version strings that are compatible with the Semantic
Versioning spec
- It is more common to use hyphens in executable names than
underscores
- The Semantic Versioning spec forbids using an underscore, and
specifies that prerelease versions can use hyphens [4]:
Section 9:
A pre-release version MAY be denoted by appending a hyphen and a
series of dot separated identifiers immediately following the patch
version. Identifiers MUST comprise only ASCII alphanumerics and
hyphens [0-9A-Za-z-].
[...]
Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
That is, there's an argument for the format of:
some-app_1.0.0-beta.1_linux_x86-64.tar.gz
rather than:
some_app-1.0.0-beta.1-linux-x86_64.tar.gz
because `_` fully separates the components of the first, and `-` does
not separate the components of the second (due to the `-beta` part of
the version string). This does ignore the convention of `_` as an
inter-word space, however.
[1] https://github.com/exercism/v2-configlet/releases
[2] exercism/cli#700 (comment)
[3] https://github.com/exercism/cli/releases/tag/v3.0.12
[4] https://semver.org/
exercism/configlet#363
exercism/configlet#24
exercism/configlet#705
Before this commit, the release assets were named like:
configlet-linux-64bit.tgz
configlet-mac-64bit.tgz
configlet-windows-64bit.zip
configlet_4.0.0-beta.7_checksums_sha256.txt
With this commit, the next release will have assets named:
configlet_4.0.0-beta.8_checksums_sha256.txt
configlet_4.0.0-beta.8_linux_x86-64.tar.gz
configlet_4.0.0-beta.8_macos_x86-64.tar.gz
configlet_4.0.0-beta.8_windows_x86-64.zip
Where we:
- Make the archive naming format match that of the checksums file
- Add a version string
- Delimit with an underscore, not a hyphen
- Rename `64bit` to `x86-64`
- Rename `32bit` to `i386`
- Rename `tgz` to `tar.gz`
- Rename `mac` to `macos`
So far, we have only released configlet for x86-64, and the release
assets have always had an ambiguous `64bit` in the names. This naming
format was old (added by d4c6e26836a5, 2020-10-09), and was ultimately
inherited from:
- the `exercism/configlet-v2` releases [1]
- the `exercism/cli` releases [2][3]
However, we're getting closer to adding releases for other 64-bit
architectures, so it's especially important to change the names now.
The rationale for the particular use of underscores and hyphens is:
- We want to have the version string in the asset filenames
- Configlet uses version strings that are compatible with the Semantic
Versioning spec
- It is more common to use hyphens in executable names than
underscores
- The Semantic Versioning spec forbids using an underscore, and
specifies that prerelease versions can use hyphens [4]:
Section 9:
A pre-release version MAY be denoted by appending a hyphen and a
series of dot separated identifiers immediately following the patch
version. Identifiers MUST comprise only ASCII alphanumerics and
hyphens [0-9A-Za-z-].
[...]
Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92
That is, there's an argument for the format of:
some-app_1.0.0-beta.1_linux_x86-64.tar.gz
rather than:
some_app-1.0.0-beta.1-linux-x86_64.tar.gz
because `_` fully separates the components of the first, and `-` does
not separate the components of the second (due to the `-beta` part of
the version string). This does ignore the convention of `_` as an
inter-word space, however.
[1] https://github.com/exercism/v2-configlet/releases
[2] exercism/cli#700 (comment)
[3] https://github.com/exercism/cli/releases/tag/v3.0.12
[4] https://semver.org/
exercism/configlet#363
exercism/configlet#24
exercism/configlet#705
From @vbuell in exercism/interactive-cli-walkthrough#58:
The text was updated successfully, but these errors were encountered: