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

Should we deprecate cask DSL versions? #15782

Closed
jawshooah opened this issue Dec 12, 2015 · 5 comments
Closed

Should we deprecate cask DSL versions? #15782

jawshooah opened this issue Dec 12, 2015 · 5 comments

Comments

@jawshooah
Copy link
Contributor

With #15381 out of the way, casks should no longer be out of sync with the core library. From here on out, no cask should ever be using a DSL that's newer than the one in core (since updating casks requires running brew update, which will update core as well).

So what's the point of maintaining a DSL version? Keep in mind that if we do so, every time a cask update includes a new DSL element, we'll need to remember to bump the header as well.

/cc @caskroom/maintainers

@jawshooah jawshooah added discussion awaiting maintainer feedback Issue needs response from a maintainer. labels Dec 12, 2015
@jawshooah
Copy link
Contributor Author

The way I see it, these are the problem scenarios:

  • We make breaking changes to the DSL, and:
    • we forget to update a cask in one of our repos
    • an external tap maintainer is slow to catch up

In either case, we would error out regardless of whether we checked the cask's DSL version. So I don't see the point in the added maintenance burden.

@MikeMcQuaid, I'm curious to hear your take on this. How does Homebrew handle breaking DSL changes?

@vitorgalvao
Copy link
Member

I’m all in favour of this.

@adidalal
Copy link
Contributor

Also in favor of this. Would also encourage contributions like #15643 as they purely add functionality - and we should make that contribution process as easy as possible.

@MikeMcQuaid
Copy link
Member

@jawshooah We basically never (intentionally) break backwards compatibility and just tell people to brew update if they hit forwards compatibility issues. When we're deprecating parts of our API we never actually remove the API method but make them print warnings on use and then eventually fail (which means the Formula parses but fails at audit or run time).

@jawshooah jawshooah removed the awaiting maintainer feedback Issue needs response from a maintainer. label Dec 14, 2015
@jawshooah
Copy link
Contributor Author

@MikeMcQuaid That sounds like a good strategy going forward.

Closing this, since it seems we have a consensus. Maintainers, feel free to re-open if you think this requires more discussion.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants