This is a rough road map of how we imagine getting Buster.JS to a rock solid v1.0. When we slap Buster.JS with the big 'ole "1.0", we guarantee that:
- Tests will not break (false positives/negatives, other breakage) when upgrading Buster.JS
- Extensions will not break from one release to another
- The APIs that make up Buster.JS will stay backwards-compatible
- The testing experience will be stable and fun
- Buster.JS works equally well on Linux, Windows and OSX
Another goal of 1.0 is to have APIs that we feel gives us some room to "grow" new features in the future. Obviously, this is a "soft goal", and one that's hard to quantify, but it will at least account for some of the more lofty dreams we currently have.
When will you support Windows?
Windows support is a requirement for us to tag Buster.JS with "1.0", but we haven't planned it in more detail than that. If you use Windows and want to help, refer to Windows support status.
Buster.JS 0.6 (AKA Beta 4)
Buster.JS 0.7 (AKA Beta 5/RC 1)
The final "big" changes will land. Bug fixes. New documentation site.
- Naming changes. See this thread, and this thread. Most importantly, some generally useful modules gain fully stand-alone names (i.e. they'll drop the buster- prefix and/or change names altogether).
- Internal browser modules will use AMD to avoid leaking globals.
buster-resourcesAPI change. The proposed change gives resources the ability to have multiple representations, based on the desired content type. This will significantly up the game for extensions that make big changes to resources, such as compile-to languages and other pre-processors.
buster-testchanges. Currently, every configuration group is run as isolated test runs, and the dots reporter has a very specific mode for the multi-browser runs. The proposed change fixes both of these by representing all configuration groups with a test runner. All of them will be coordinated by a master "multi runner", and this is where you plug in the reporters etc. This removes some duplication in the implementation, makes it possible to have e.g. one XML report for any number of buster.js configuration files, and makes environments a native part of the test runner/reporters.
- New documentation site. Work is being put into a new documentation site based on Sphinx. There are plans for API docs to be extracted from module Readme's and source code. The site is proposed to launch with Buster 0.7.
buster-assertions1.0. There's currently a pending change for
assert.exception. Additionally, referee's equals and match algorithms will be extracted into a separate module (that among others Sinon.JS will use).
- buster-node. A package that provides the full Buster.JS testing experience, but only for node. Main goal is to reduce dependency count for node-only projects.
In progress. Expected to complete in August.
Extract comparison functions from buster-assertions Extract Buster's event emitter Rename buster-assertions Add AMD support to Referee
- Integrate Referee in Buster
If necessary, we will fix bugs and iron out issues from 0.7 and release as successive RC's until things stableize. At this point, we expect roughly one RC per week/two weeks until we hit the sweet-spot, which is...
Buster.JS 1.0 will be released when 0.7 has been tested in the wild, any
breaking bugs have been fixed, and all current extensions have been updated
to accommodate for API changes etc.
buster-static will likely
not be included with 1.0, but installable as an add-on.
buster-static that can do both Node and Browser tests
from within the browser is included in the default installation.
Installers for OSX and Windows.
buster-ci a new binary that can automate everything - start
server, capture browsers, run tests, wind down. Headless testing.
thread for the current draft, and pitch in your own ideas/requirements.