Release 13.7.0 #4854
Comments
|
It doesn't seem like it's ready for release. Renaming rules causes few issues, which are not taken care of.
|
|
Thanks for catching these.
I can't think of a solution to this confusion.
It should be, but it currently produces: Offhand, I'm unsure where the
We could mitigate this somewhat by including the alias in each description. For example: " With these issues in mind, I'm wondering whether aliasing the rules, like ESLint did, is the right way to go about this. Perhaps we should revert to a deprecate and remove approach, even if that means everyone will need to update and publish new configs to avoid the deprecation warnings. Can anyone see another solution to the issues above? |
Does anyone have any objections to this? If not, I'll reach out to see if anyone has time to make these changes. |
I think this is probably the neatest approach in the long run. |
|
OK, let's deprecate. The delayed release of 13.7.0 is on me because it was my suggestion to take ESLint's approach that's led to these unforeseen problems. Unfortunately, I've had little time for OSS this past month to remedy the issue, and I'll unlikely have much time for the next couple. Has anyone got time to re-add the |
The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: stylelint#4854 (comment) [2]: stylelint#4854 (comment) [3]: stylelint@e93e44c
The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: stylelint#4854 (comment) [2]: stylelint#4854 (comment) [3]: stylelint@e93e44c
The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: stylelint#4854 (comment) [2]: stylelint#4854 (comment) [3]: stylelint@e93e44c
As discussed in issue stylelint#4854, the desired approach is to deprecate the *-blacklist/*-requirelist/*-whitelist rules. The first step I've taken to doing this is to make copies of all the rules. The commands used to generate this commit were: - find . -name '*-allowed-list' -exec sh -c 'cp -R "$1" "${1%-allowed-list}-whitelist"' _ {} \; - find . -name '*-disallowed-list' -exec sh -c 'cp -R "$1" "${1%-disallowed-list}-blacklist"' _ {} \; - find . -name '*-required-list' -exec sh -c 'cp -R "$1" "${1%-required-list}-requirelist"' _ {} \;
The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: stylelint#4854 (comment) [2]: stylelint#4854 (comment) [3]: stylelint@e93e44c
The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: stylelint#4854 (comment) [2]: stylelint#4854 (comment) [3]: stylelint@e93e44c
The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: stylelint#4854 (comment) [2]: stylelint#4854 (comment) [3]: stylelint@e93e44c
|
I've opened #4892 to re-instate the rules as deprecations. |
|
If anyone has time, it'd be fantastic to get a second review on #4892 so that we can release 13.7.0. The following are also in need of second reviews, but we won't delay the release further if no one has time to review them too: |
As discussed in issue stylelint#4854, the desired approach is to deprecate the *-blacklist/*-requirelist/*-whitelist rules. The first step I've taken to doing this is to make copies of all the rules. The commands used to generate this commit were: - find . -name '*-allowed-list' -exec sh -c 'cp -R "$1" "${1%-allowed-list}-whitelist"' _ {} \; - find . -name '*-disallowed-list' -exec sh -c 'cp -R "$1" "${1%-disallowed-list}-blacklist"' _ {} \; - find . -name '*-required-list' -exec sh -c 'cp -R "$1" "${1%-required-list}-requirelist"' _ {} \;
The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: stylelint#4854 (comment) [2]: stylelint#4854 (comment) [3]: stylelint@e93e44c
* Make copies for *-blacklist/*-requirelist/*-whitelist rules As discussed in issue #4854, the desired approach is to deprecate the *-blacklist/*-requirelist/*-whitelist rules. The first step I've taken to doing this is to make copies of all the rules. The commands used to generate this commit were: - find . -name '*-allowed-list' -exec sh -c 'cp -R "$1" "${1%-allowed-list}-whitelist"' _ {} \; - find . -name '*-disallowed-list' -exec sh -c 'cp -R "$1" "${1%-disallowed-list}-blacklist"' _ {} \; - find . -name '*-required-list' -exec sh -c 'cp -R "$1" "${1%-required-list}-requirelist"' _ {} \; * Re-instate *-blacklist/*-requirelist/*-whitelist rules The aliasing approach taken for these rule renaming presented user experience problems [1]. To resolve these problems the preference is to revert on the aliasing strategy and instead return to a deprecation strategy. The first step towards this is re-instating these rules. As per the preference of jeddy3 [2] these rules are re-instated using a copy and paste strategy, with the expectation these will be removed in the next major release. An approach that didn't involve copy and pasting was previously introduced in [3] and could be looked at again if maintaining this duplicate code proves problematic. [1]: #4854 (comment) [2]: #4854 (comment) [3]: e93e44c * Deprecate *-blacklist/*-requirelist/*-whitelist rules This applies deprecation warnings when these rules are used, tests to check there is a deprecation warning and re-includes them in documentation. * Deprecation links point to GitHub tag This reflects the documentation on deprecating stylelint rules [1] by linking to the GitHub website rather than stylelint website, so that the link can continue operating indefinitely. As suggested in the PR [2] these have been linked to the anticipated next release of stylelint, so these links will not be actually operational until this tag is made. [1]: https://github.com/stylelint/stylelint/blob/858dcd584224042654d80ce8fa8ad71f41f20808/docs/developer-guide/rules.md#deprecate-a-rule [2]: #4892 (comment)
jeddy3
added
status: wip
|
Done 🎉 Thank you to everyone who contributed to this release! In the past, we've been pretty timely with our releases. This one dragged out a bit; I think mainly because those of us with the permissions to put a release out lack the time to do it. We're a bottleneck. I suggest we give more contributors access to perform releases (and the permissions they need to evolve stylelint's contributing and release processes). |
It'll be great if we could get out a release this week. I'll try to make time for the release itself, but we need:
It'll be nice to have:
The text was updated successfully, but these errors were encountered: