Proposal: adopt semantic versioning rules and postpone 1.0.0 release

[jerch]

Semantic versioning is a great way for peeps to get an idea of the state of some piece of software. Since xterm.js will have some impact in the node and browser world Im suggesting to adopt rules from semantic versioning to give the audience a chance to catch the actual state of xterm.js and its development.

To phrase it differently - is xterm.js ready for a 1.0.0. release yet?

I have to admit that I would expect at least the following for a so called stable release:

• at least 95% test coverage (not a good marker for a parser driven piece of software since it will neglect the edge cases, but better than nothing)
• if there is a demo, it should work (the demo still has many glitches)
• 95% documentation of exported features (API and stuff)
• somewhat stable (no big refactoring in sight including API changes)

If you like the idea of adopting semantic versioning I propose to leave the 1.0.0 version idea and change it to an interim beta release with some minor version number. This would lower the burden to maintain a stable release with already known flaws and give time to focus on the problems at hand like refactoring and test coverage.

[Tyriar]

v1 doesn't necessarily mean everything is amazing. If anything a v1 release would enable semantic versioning to do what it does which would be helpful for consumers as the API will not get any breaking changes until there is another major version bump. Before v1, API breakages are disregarded as the API is seen as unstable, meaning consumers need to lock against the patch version, not the minor version. Also as far as I can tell, there haven't really been any breaking changes recently, only fixes and additions.

That being said, it may make sense to backtrack until discussions that I just started today, #195 and #196 are resolved. I do not think the lack of tests is a reason not to do a v1 release though, tests and documentation can be continuously improved in minor/patch releases.

[jerch]

I guess I just got the bad cop role and I dont like it but - I see the following changes ahead that might break the API since they are somewhat fundamental:

• separate DOM related stuff (input handling + presentation) from inner state handling
• separate parsing/tokenizing from emulator state handling
• maybe more changes to the inner state handling to get a more comprehensible testable emulator model

For me xterm.js is not ready for 1.0.0 yet (from a QA point of view), maybe we have different views on what a v1 release should deliver. Well it is just a proposal ;)

All of this is also addressable with any next major release, of course.

[Tyriar]

I wouldn't necessarily think those 3 things would break the API though? The main Terminal object would just hook into the newly refactored parts.

[jerch]

...ah yes from an outer perspective xterm.js is IMO mature enough to hide those changes behind some abstraction layer. Well - not sure about the output rendering on this though...

[parisk]

Thanks for your proposal @jerch. While there is much space for improvement in xterm.js, this does not mean that we should backtrack on the 1.0 release (which has already been released btw).

I will stick mostly on the goal that you set on this issue:

give the audience a chance to catch the actual state of xterm.js and its development.

Do you believe that a "Project status" section in the readme explaining the current status of the project, how versioning works, release cycles etc. could help? This could be also combined with #198.

[jerch]

...(which has already been released btw)...

Oops didnt notice...

Yes I think some clarification in the README is quite useful.