5.0.2 gives warning about deprecated rules

[rbirkgit]

Using tslint with 5.0.2 I get this:

Warning: no-duplicate-case rule is deprecated. Replace your usage with the TSLint no-duplicate-switch-case rule.
Warning: no-var-self rule is deprecated. Replace your usage with the TSLint no-this-assignment rule.
Warning: valid-typeof rule is deprecated. Replace your usage with the TSLint typeof-compare rule.

Seems these rules were removed in the main part of the recommended rules set, but then they are turned on again at the end:

    /**
     * Deprecated rules.  The following rules are deprecated for various reasons.
     */
    "missing-optional-annotation": false,  // now supported by TypeScript compiler
    "no-duplicate-case": true,
    "no-duplicate-parameter-names": false, // now supported by TypeScript compiler
    "no-empty-interfaces": false, // use tslint no-empty-interface rule instead
    "no-missing-visibility-modifiers": false, // use tslint member-access rule instead
    "no-multiple-var-decl": false,         // use tslint one-variable-per-declaration rule instead
    "no-stateless-class": true,
    "no-switch-case-fall-through": false,  // now supported by TypeScript compiler
    "no-var-self": true,
    "react-tsx-curly-spacing": true,
    "typeof-compare": false,               // the valid-typeof rule is currently superior to this version
    "valid-typeof": true,

[karfau]

I would also love to understand how rules are supposed to be deprecated.
The README.md states about recommended_rules.js:

Also, please note that adding a rule to the recommended ruleset is considered backwards compatible. If you rely on version ranges in your dependencies then you may find that new rules being added to the product create violations and fail your build.

These sentences are confusing for me a bit since it seems like they contradict each other.
But if tslint-microsoft-contrib offers a "stable recommended rule set" that one can extend from, instead of en- or disabling rules that moved to/ should be replaced by core rules, is there a clear flight plan for how this happens?

Would it be an option to just enable those recommended new rules instead of the deprecated ones, by putting those changes behind a proper semantic version increase?

[HamletDRC]

@karfau - Rules are deprecated when something is added to TypeScript or TSLint that makes the rule obsolete. Typically, we turn the rules off in recommended_ruleset.js for a release or two. Eventually we remove the rule from the code base.
As we add new rules, if they are good rules, then we recommend that people turn that rule on in recommended_ruleset.js.
Any change to recommended_ruleset.js will be versioned.

It sounds like what you're asking for is to increase the major version number for every new rule added to the recommended_ruleset.js because it might break somebody's build if they rely on version ranges. I personally don't see the point, but others may disagree. Feel free to file a an issue for this and if a bunch of people upvote then I can do it. At the end of the day, there is the same problem regardless: if you use wildcards then you have a chance to take a bad dependency and fail your build, which is try for project dependency.