[proposal] v2.0.0 goals

[jerch]

This is just a quick collection of ideas that popped up in older issues and might be worth targeting with a 2.0.0 release. Some of them are fundamental and need a proper design decision.
Up for discussion - feel free to add other ideas or edit the list.

• decision on basic development languages / env
  • logic
    • vanilla ECMA5
    • vanilla ES6
    • TypeScript
    • others?
  • CSS
    • native
    • LESS
    • SASS
    • others?
• enable code separation over distinct files / subpackages
  • npm
  • ES6 packages
  • TypeScript packages
  • webpack
  • gulp
  • grunt
  • browserify
  • others?
• rewrite code base
  • rewrite/split code base upon language/env decision
  • separate parser from terminal
    • with generators (ES6 target only)
    • with events
    • with callbacks
  • separate UI from terminal state handling
    • define interfaces for separation
    • separate user output (HTML, others possible as well)
    • separate user input (user events)
    • move terminal to webworker (state handling + pty IO)
  • setup tests for all interfaces
• others?

Details

• Browser and browser version: all
• OS version: all
• xterm.js version: 2.0.0

[Tyriar]

I think the rewriting should be done slowly over time, not necessarily commit to "rewrite the code base" for v2.0.0. A large portion of the code is quite a mess right now and we certainly shouldn't rush any refactors.

[Tyriar]

Part of my thinking here is that master should always be shippable, I say this largely because vscode doesn't currently ship a tagged release but an arbitrary commit. So the longer xterm.js goes without a release the more risk is associated with the vscode terminal essentially. Also it gets plenty of testings via vscode so frequent smaller releases are possible (and shipping often is good).

[ayapi]

basic development languages / env

+1 to vanilla js and native css 'cause i hope xterm.js to be standard :)

[parisk]

It would be better if we didn't see 2.0 as a "big release" but just as an API breakage point, because we have to split the core into multiple files (#158).

I would restrain on adding any other goals in this release. I agree with @Tyriar that rewrites should happen slowly and gradually and I will add that everything we do has to be purposeful.

For example, we should switch to a CSS preprocessor only if it makes sense for xterm.js. Right now there is no open issue for discussion this, so I do not find any reason to squeeze it into the 2.0 release.

Last, I will agree with @Tyriar again that the master should be always shippable. Some regressions are 🆗 to exist, but it should still be shippable, in order to be able to push hotfixes at any time, fast.

[jerch]

Closing the issue since it doesn't fit the versioning strategy.