Release 15.11.0

[mattxwang]

I know we're still in the middle of preparing the next major version, but we've recently merged a few changes that affect main; looking at #7212,

• the new ignoreRules option for max-nesting-depth
• 4 (!) different fixes for declaration-block-no-redundant-longhands (at this point, my mortal enemy 😓 )

Once we merge in #7242, I think it's a good time for us to cut a release. What are our thoughts? I'm happy to manage as much of the process as possible (I'll just need someone to review my PRs in the other repos).

checklist

• stylelint release
• stylelint-config-recommended update/release
• stylelint-config-standard update/release
• stylelint.io update
• stylelint-demo check
• tweet

[ybiquitous]

Agree with the new release. 👍🏼

And we can include #7234 too.

[Mouvedia]

What are our thoughts?

I think main should also have #7237.

• Bump known-css-properties from 0.28.0 to 0.29.0 #7247

[mattxwang]

All the discussed PRs have been merged, so I'm starting the process now. Marking as WIP.

[mattxwang]

@ybiquitous have the branch protections on main (or other permissions) changed since I last released? I'm unable to git push after running npm run release, with the following output:

$ git push
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes must be made through a pull request. 10 of 10 required status checks are expected.
To github.com:stylelint/stylelint.git
 ! [remote rejected]     main -> main (protected branch hook declined)
error: failed to push some refs to 'github.com:stylelint/stylelint.git'

This has happened a handful of times already when I've tried to cut releases, so not sure exactly what's going on...

[mattxwang]

To temporarily resolve this, I toggled the "Do not allow bypassing the above settings" option in the branch protection settings (it's now back to its original setting). I've now published 8914d46 and the related tags, but I'm thinking that this is probably not a good path forward? Any thoughts?

[mattxwang]

Sorry for a bit of spam, but want to be transparent. In terms of tasks:

• noticed that for other PRs, releases have just merged in the stylelint.io change w/out a review - so I've done that too
• did the demo check
• Tweeted

I think this release is done, but I'll leave this up for a moment in case others want to comment?

[ybiquitous]

@mattxwang Great. Thank you for your work! 👏🏼

I'm thinking that this is probably not a good path forward? Any thoughts?

Make sense. The current rule is too strict when releasing. And I recommend migrating to rulesets, which have several advantages than protection rules.

[ybiquitous]

I've created a ruleset to try out (still disabled). Can you take a quick look?

[mattxwang]

I've created a ruleset to try out (still disabled). Can you take a quick look?

Thanks! To be honest, I'm not super familiar with rulesets. I did take a look at the GitHub Docs, and in "Rule layering", it says the following:

If the same rule is defined in different ways across the aggregated rulesets, the most restrictive version of the rule applies. As well as layering with each other, rulesets also layer with protection rules targeting the same branch or tag.

My understanding is that this might interact with "Do not allow bypassing the above settings", which is the "most restrictive" version - so perhaps this ruleset doesn't fix the core problem (which is bypassing the restriction on admins from pushing to main)? However, I might be missing something (as I mentioned, I'm not familiar with rulesets at all). I'm also happy to be a guinea pig in case you want to "try" this ruleset on me for the next release?

[mattxwang]

(also, will close this issue now as the release is fully completed)

[ybiquitous]

@mattxwang Your concern is right.

If we continue the "most restrictive" setting (that is, forbid anyone to bypass), we should make the "Bypass list" of the ruleset empty. This is the safest against any potential missed operations.

I'll dig into the rulesets more. Since the ruleset feature shows more helpful error messages than protection rules, I think it's valuable to migrate.

[ybiquitous]

@mattxwang I've migrated copied all rules from the branch protection to the ruleset (still disabled). Our new operation with the ruleset should be as follows:

1. npm run release -> git push should fail due to the ruleset ("Require a pull request before merging").
2. Disable the ruleset temporarily. (Active -> Disabled on GitHub.com)
3. Re-run git push --follow-tags.
4. Re-activate the ruleset.

It also may be good to disable the ruleset before npm run release. Any thoughts?

[mattxwang]

@mattxwang I've migrated copied all rules from the branch protection to the ruleset (still disabled). Our new operation with the ruleset should be as follows:

1. npm run release -> git push should fail due to the ruleset ("Require a pull request before merging").
2. Disable the ruleset temporarily. (Active -> Disabled on GitHub.com)
3. Re-run git push --follow-tags.
4. Re-activate the ruleset.

It also may be good to disable the ruleset before npm run release. Any thoughts?

This sounds good to me! I'm happy to run through the next release and not disable the ruleset, to confirm that step 1 happens (the git push should fail due to the ruleset). How does that sound?

[ybiquitous]

Good. I've just enabled the ruleset. Please do that if you perform the next release. 👌🏼

Note the old protection rule is still alive. After a while, if it's OK, let's remove it.