Better communication around releases

[ajafff]

To me the release of v5.0 seemed to be a little rushed and not well communicated.

I'd like to propose some changes to the release process and also discuss your ideas.

• Cut beta releases and RCs at least for major releases, ideally also for minor releases.
  • integrators like vscode-tslint can take on the changed API and catch breaking changes that slipped in unnoticed (Breaking API changes for tslint integrators are not documented in the v5 release notes #2439)
  • 3rd party tools and rule libraries can release a new version that is compatible with the new version
  • early adopters find bugs before they get released to all users
  • this gives us the ability to identify and possibly revert changes that are too breaking and don't allow a backwards compatible upgrade (like the removal of Fix and createFix)
  • seamless upgrade process for users, because once we cut the stable release most tslint related tools just work
• Maintain a roadmap that contains rough release dates for major (and minor) releases
  • to me it felt like v5.0 was just there all the sudden. There may be others that were a bit overwhelmed by all the breaking changes, too.
  • a major version bump of tslint often requires a new major version of 3rd party tools as well. that process needs some time to prepare and communicate
• Introduce a deprecation policy
  • don't just remove or break public APIs because they are no longer needed in tslint core

[adidahiya]

Eh, I know it may seem like the release was rushed and there were some breaks but we're getting all that signal because many people did upgrade to the latest version. There would have been fewer upgraders if it was a -beta or -rc release. It's easy enough to cut a v5.0.1 for the most egregious issues and move on with things. In the case of vscode-tslint, 0.9.0 suggests that some people did upgrade to 5.0.0-dev.0. We'll consider 6.0.0-beta when the time comes around for that. I don't want to do it for minor releases; that seems like too much of a burden.

My preferred solution to the prerelease problem is snapshot releases on every commit to develop (on the next dist-tag, similar to typescript nightlies). Open to PRs for this.

Re: deprecation, are there specific instances of things that should've had deprecation warnings? We mostly try to be good about this, but I agree there's room for improvement.

[ajafff]

My preferred solution to the prerelease problem is snapshot releases on every commit to develop (on the next dist-tag, similar to typescript nightlies)

That sounds like a good thing to do

Re: deprecation, are there specific instances of things that should've had deprecation warnings?

#2403, #2370 should have had deprecation warnings. Migration for the latter was easy and backwards compatible. But the former had no upgrade path that would be backwards compatible. That means every rule package that wants to add fixes needs to bump the peer dependency to tslint@^5.0.0 which in turn would result in a new major version for most packages.
I know I approved those PRs but only now I now what impact it had on dependent packages.

I just want us to be more cautious with such changes. For example
https://github.com/palantir/tslint/pull/1984/files#diff-5bbd61febe63edf0d401f0b47f8f3facR23 landed with a minor release and broke tslint-eslint-rules and maybe others. That shouldn't have happened.
A positive example is #1867 (comment)

We'll consider 6.0.0-beta when the time comes around for that. I don't want to do it for minor releases; that seems like too much of a burden.

Works for me.

Do you have a specific release shedule (something like weeklyish patch releases, monthlyish minor releases and a major version every 6 months...) or are releases done as needed? And could this be documented?

[JoshuaKGoldberg]

+1 to weeklyish patch releases. I'm on a team now that's starting to actively add TSLint fixes as we see them. It'd be nice to have nightly dev releases on npm that we can pull in.