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

Cookstyle configuration "streams" #967

Open
dafyddcrosby opened this issue Dec 14, 2023 · 1 comment
Open

Cookstyle configuration "streams" #967

dafyddcrosby opened this issue Dec 14, 2023 · 1 comment
Labels
Status: Untriaged An issue that has yet to be triaged. Type: Design Proposal Community survey of a proposal.

Comments

@dafyddcrosby
Copy link
Contributor

Motivation

As a Chef power user,
I want to use the latest and greatest Cops,
so that I can see and fix problems early, and get the most out of Cookstyle.

As an off-and-on Chef user,
I want to be able to occasionally update the set of Cops,
so that I can incrementally improve my codebase when I have time.

As a CI owner/someone who can't change code often,
I want to see a CI that doesn't go red without notice,
so that I can do other things besides chasing style points.

Specification

The current thinking is something like TargetChefVersion in .rubocop.yml. We can specify a CookstyleCopStream which has values of stable (the current set, which almost never changes save for bug fixes), dates for yearly snapshots (eg YYYYMMDD) so that new Cops can be ratcheted in easily, and latest (what it says on the tin).

Downstream Impact

  • Existing customers, generally speaking, don't need to change. Stable is the default.
  • Folks who are comfortable with Cookstyle/Chef/Ruby can do new cop development without the worry of breaking.
@dafyddcrosby dafyddcrosby added Status: Untriaged An issue that has yet to be triaged. Type: Design Proposal Community survey of a proposal. labels Dec 14, 2023
@dafyddcrosby
Copy link
Contributor Author

After stepping away from the keyboard, I think we'll want to strike stable and instead have the first snapshot be the default. We don't want to imply that it's any more stable than the other snapshots or latest, just that it's a fixed point in time, showing how far removed that first snapshot is from the other snapshots/latest as a point of reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Untriaged An issue that has yet to be triaged. Type: Design Proposal Community survey of a proposal.
Projects
None yet
Development

No branches or pull requests

1 participant