Skip to content
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

Add Rust, version 0.10 #4699

Closed
wants to merge 1 commit into from
Closed

Add Rust, version 0.10 #4699

wants to merge 1 commit into from

Conversation

tapeinosyne
Copy link
Contributor

As a point of interest, the Rust homepage recommends the Nightly version (which is already available in our caskroom/versions tap) over the latest stable release.

Which release should we consider canonical, and thus include it in the main repo?

@rolandwalker
Copy link
Contributor

That's a good question. What if we accept this Cask, but add a caveats alerting users to the nightly? Reasonable compromise?

@passcod
Copy link
Contributor

passcod commented Jun 5, 2014

Rust development is (currently) so fast that numbered versions are literally outdated as they are released.

Additionally, some libraries and binaries track master, and some libraries and binaries follow the version they were built against. Which can vary. My intuition would be to make the nightly the default version, until 1.0 comes around (at which point 1.0 should be the main version), and make each numbered version available in /versions.

Thus one could install both the nightly and any and all numbered versions they need.

From the official IRC channel:

11:49:09 < mcpherrin > passcod: I think master ought to be default
11:49:11 < cmr > passcod: master should be the default.

@mcpherrinm
Copy link

Rust releases are not intended as anything more than checkpoints along the road at this point, and in general you shouldn't be recommending them as default for anything.

@rolandwalker
Copy link
Contributor

Thanks for the input, Rustians!

The nightly should remain in the versions Tap, because that's how we have things organized/documented. Keeping each of the numbered releases in versions might
also be helpful to someone, and there is no reason not to. I have been intending to
the same for all Java releases, but haven't communicated it.

@ndr-qef I am going to close.

@vitorgalvao
Copy link
Member

The nightly should remain in the versions Tap, because that's how we have things organized/documented.

I’d argue that actually the documentation supports the inclusion of the nightly here in this case, since it is indeed the standard. On the other hand, that same document also says nightlies should go on caskroom/versions, so we can take our pick.

@tapeinosyne
Copy link
Contributor Author

@rolandwalker, as the Rust nightly is indeed the recommended installaton method, would you be willing to reconsider?

@rolandwalker
Copy link
Contributor

@ndr-qef sure, if enough maintainers want to change the policy. The rule "all nightlies go in versions" precedes me on this project; I'm just following the existing guidelines.

A similar case would be Webkit.app .

You should submit a doc patch removing the rule on nightlies.

@vitorgalvao
Copy link
Member

As someone who “was here at the time”, I believe we should include the nightly in the main repo. As @mcpherrinm pointed out, there isn’t really a stable version, so including the nightly actually abides by the guidelines. Since this is the main repo, we should consider for inclusion what the developers considers the main, recommended version.

I’m also partial to @passcod’s opinion on this, as he was also present at the time of the “split” to the versions repo (he was already a collaborator when I joined) and is a rust developer.

To be clear, having been here is a context, not an argument. The project has already changed so much that old rules definitely benefit being revisited by new eyes. The versions repo came to be mainly as a response to old versions of paid apps, but even at the time we thought we’d deal with it by managing all versions inside a single cask.

@rolandwalker
Copy link
Contributor

It's an important context though, as I am trying to keep continuity rather than advance an argument.

@passcod is still an honorary maintainer, so I count three maintainers in favor of a change, zero opposed. So that's a done deal in my view.

For the sake of users and first-time Cask authors, I'd like to change not only the docs, but also review homebrew-versions for similar Casks which we should move back here for consistency.

@tapeinosyne tapeinosyne deleted the rust branch July 4, 2014 00:29
@tapeinosyne tapeinosyne mentioned this pull request Jul 4, 2014
@Homebrew Homebrew locked and limited conversation to collaborators May 8, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants