anaconda.rb: use set_permissions

[vitorgalvao]

To be merged after #13612 and a new release.

[jawshooah]

We should wait to merge this until we have pushed a new release following #13612. Do we need to increment the DSL version number as well? I.e. cask :v1_1 => cask :v1_2?

[vitorgalvao]

wait to merge this until we have pushed a new release

Oh, right, I keep forgetting we need to do that before features are available.

Do we need to increment the DSL version number as well?

No, lets keep it as is. In fact, I’ve been thinking we do away with that altogether, at least until we get to a stage other than alpha. Not like not updating the number is having any real consequences, and we should likely focus on getting stuff to work, first. What do you think?

[jawshooah]

Since #7530, we've been checking the DSL version headers against a minimum arbitrarily defined at 1.0. No casks currently violate this requirement, so it's not accomplishing anything.

The right way to do this, if we wanted to do it at all, would be to define a DSL_VERSION constant somewhere in the core, incremented whenever we make a DSL change, and check that the version listed in a cask's header is at or below that version.

For example, say a cask foo has the header cask :v1_4. A user wants to install this cask, but the installed version of brew-cask has DSL_VERSION = 1.3. If they attempt to brew cask install foo, they'll get an error message informing them that their brew-cask is out of date, and that they need to brew upgrade brew-cask before they can install foo.

In short, a cask can be installed if and only if its stated DSL version is less than or equal to the DSL_VERSION defined in the currently installed brew-cask.

[vitorgalvao]

Right, I understand the goal of the system and how it’s meant work (and agree it’s a win, at the very least in user experience), but the question is, since we’re not actually doing said checks yet, is it worth at all to increment the number until we start performing said checks?

[jawshooah]

Good point. I guess I was thinking that we should be consistent with #12981 and #12986, even if the behavior isn't there yet. That way, we at least have a sound basis to work from when we do implement these checks.

[jawshooah]

Actually, if you're on board, I may just add the implementation now, so we can roll it out with this next release. What do you think?

[vitorgalvao]

Sure. Sounds good.

[vitorgalvao]

#13612 is merged and we have a new release, so merging this.

[vitorgalvao]

Merged as 6fb3d5f.