Skip to content

Latest commit

 

History

History
78 lines (52 loc) · 5.95 KB

2019-10-10.md

File metadata and controls

78 lines (52 loc) · 5.95 KB
Raw

2019-October-10 ESLint TSC Meeting Notes

Transcript

https://gitter.im/eslint/tsc-meetings/archives/2019/10/10

Attending

  • Brandon Mills (@btmills) - TSC
  • Toru Nagashima (@mysticatea) - TSC
  • Ilya Volodin (@ilyavolodin) - TSC
  • Kevin Partington (@platinumazure) - TSC

Additionally, the following individuals are not in attendance but support consensus:

  • Nicholas C. Zakas (@nzakas) - TSC
  • Gyandeep Singh (@gyandeeps) - TSC

Topics

require-atomic-updates false positive

  • TSC Summary: require-atomic-updates is currently on in eslint:recommended and appears to be flagging safe code (see examples in comments above).
  • TSC Question: Can we remove this rule from eslint:recommended while we decide how we want to move forward with the rule? This should be fine to do in a semver-minor release because it will result in fewer errors being reported.
  • @platinumazure points out that currently our semantic versioning policy states that changes to eslint:recommended are semver-major.
  • When that policy was written, it plausibly had in mind adding new rules and changing configurations that would make eslint:recommended more strict. This change, if accepted, would make eslint:recommended less strict. We could update the policy so that changes that relax eslint:recommended could be semver-minor or -patch.
  • @platinumazure, @btmills, @ilyavolodin, and @mysticatea are all in favor of making eslint:recommended relaxations semver-minor.
  • 👍 to changing the versioning policy and removing require-atomic-updates from eslint:recommended from @mysticatea, @btmills, @platinumazure, and @ilyavolodin.

Resolution: Update the semantic versioning policy to allow relaxing eslint:recommended in a semver-minor release and remove require-atomic-updates from eslint:recommended.

Release schedule

  • TSC Description: We have only 5 people active members of TSC currently, and we've lately been having a lot of trouble with finding available people to do releases every two weeks. We skipped number of releases in the summer due to the lack of availability. I propose that we either have to switch back to requiring only one person to do a release, or increase time between releases to once a month.
  • TSC Question: Should we accept this proposal. And if so, which one?
  • @platinumazure and @ilyavolodin prefer having two developers available for a release to check each other's work and debug together if something breaks.
  • @platinumazure suggests single-developer releases might be easier if we merged more PRs in between releases rather than immediately before. However, we lack a way to enforce that.
  • @mysticatea prefers not to reduce release frequency because that could increase the number of PRs the release participants need to review. Releases can already take 1.5-3 hours.
  • @platinumazure suggests somehow timeboxing releases.
  • @mysticatea suggests canary builds that are released each time we merge to master as a way of reducing load on the release team. @btmills points out that people don't often use betas and release candidates of major versions. @platinumazure points out that those require migration work, whereas canaries wouldn't.
  • @ilyavolodin suggests using TSC meeting time to review PRs as a group.
  • 👍 to trying a 4-week release cycle and reviewing PRs during biweekly TSC meetings until the end of the year from @ilyavolodin, @btmills, @platinumazure. @mysticatea wants to include canaries if we move to a 4-week release cycle.
  • No opposition to canary releases.
  • @platinumazure notes that we will need to update the bot and README for the 4-week release cycle.

Resolution: Until the end of the year, trial a 4-week release cycle and using TSC meetings to review PRs between releases. Add canary releases automatically after merging to master.

ESLint v7 schedule

TSC Description:

Let's discuss to schedule for the ESLint 7.0.0 release. I have a rough draft:

  • 2019-11-08 ... Start to discuss we should include what changes into 7.0.0.
  • 2019-12-05 ... Feature-freeze. After this release cycle, start to merge breaking change PRs.
  • 2020-01-31 ... Stable release.

The following items are the reason I'm thinking it's good timing:

  • In December 2019, Node.js 8.x will be EOL (https://github.com/nodejs/Release#release-schedule). We can drop supports for that then start to use async iteration (RFC40 may use async iteration).
  • We have a ton of issues/PRs that are breaking changes (https://github.com/eslint/eslint/projects/6)
  • The 1.0.0 release was 31 July 2015 and the 1.10.3 release was 1 December 2015. Since the 6.0.0 release was 21 June 2019, so the 6.x duration in the draft plan is longer than the 1.x duration (and the 2.x duration also). Therefore, from the precedent, we have enough intervals for the new major release.

TSC Question:

How should we schedule to release ESLint 7.0.0?

  • We have no reason to rush, but there's also plenty of changes to justify beginning work on v7. As long as we wait for Node 8.x EOL, anytime after that works.
  • @btmills proposes following the schedule as suggested above and letting it slip if we miss a TSC meeting or release.
  • 👍 from @platinumazure, @ilyavolodin, @mysticatea

Resolution: The proposal is accepted.

Scheduled release for October 11th, 2019

  • Nobody is available concurrently, so @btmills proposes starting 4-week release cycles by skipping this weekend's release and reviewing PR's in the next TSC meeting. 👍 from @ilyavolodin, @platinumazure, @mysticatea.

Resolution: We will not do a release on October 11th. We will review PRs in the TSC meeting on October 24th and do the next release on October 25th.