WIP Add v0.27.0 release notes

release notes/v0.27.0.md

@@ -0,0 +1,76 @@
+k6 v0.27.0 is here! :tada:
+
+This is a milestone release containing a major overhaul to the execution subsystem of k6, along with many improvements and bug fixes.
+
+## New features and enhancements!
+
+### New execution engine (#1007)
+
+After 1.5 years in the making, the k6 team is proud to release the first public version of the new execution engine, offering users new ways of modeling advanced web testing scenarios that can more closely represent real-world traffic patterns.
+
+These new scenarios are entirely optional, and existing k6 scripts and options should continue to work the same as before (with a few minor breaking changes, see below), but please [create a bug issue](https://github.com/loadimpact/k6/issues/new?labels=bug&template=bug_report.md) if that's not the case.
+
+See the [documentation](https://k6.io/docs/using-k6/executors) for details and examples, or keep reading for the summary.
+
+#### Execution scenarios
+
+Some of the currently possible scenarios were formalized into standalone executors:
+
+- Shared iterations: a fixed number of iterations are "shared" by all VUs, and the test ends once all iterations are executed. This scenario was possible with the previous `vus` and `iterations` options.
+- Constant VUs: a fixed number of VUs execute as many iterations as possible for a specified amount of time. This scenario was possible with the previous `vus` and `duration` options.
+- Ramping VUs: a variable number of VUs execute as many iterations as possible for a specified amount of time. This scenario was possible with the previous `stages` option.
+- Externally controlled: control and scale execution at runtime via k6's REST API or the CLI.
+
+And new executors were added to support some of the most frequently requested scenarios that were previously difficult or impossible to model:
+
+- Per VU iterations: each VU executes a fixed number of iterations.
+- Constant arrival rate: a fixed number of iterations are executed in a specified period of time. This allows k6 to dynamically change the amount of VUs during a test run to achieve the specified amount of iterations per period, which is useful for a more accurate representation of RPS, for example. See #550 for details.
+- Ramping arrival rate: a variable number of iterations are executed in a specified period of time. This is similar to the ramping VUs executor, but for iterations instead.
+
+#### Execution improvements
+
+- Several executors can be configured in a single test run, both sequentially and in parallel (closes #239).
+- Each executor has a `startTime` property, which defines at what time relative to the test run start it will start executing.
+- Executors have a new `gracefulStop` property that allows for iterations to complete gracefully for some amount of time after the normal executor duration is over (closes #879); even with `gracefulStop=0`, i.e. the old behavior, metrics are emitted and processed in a much saner way (closes #1033).
+- The new `execution-segment` options allow easy partitioning of test runs across multiple k6 instances. Initially this applies to configuration options like number of VUs or iterations, but opens the door to test data partitioning, an often requested feature. See #997 for more details.
+- Different executors can execute different functions other than the `default` exported one. This offers more flexibility for organizing your tests, building test suites, etc.
+- Different executors can have different environment variables or tags.
+
+
+## UX
+
+- CLI: There are separate descriptions and real-time thread-safe progress bars for each individual executor.
+- A new method to stop engine execution via the REST API (#1352). Thanks @hynd!
+
+## Bugs fixed!
+- The new execution engine by itself squashed a lot of bugs: [Do we have a full list of these? Issues that link to #1007?]
+- CLI: Stop `--http-debug` from exiting k6 on request dump error (#1402). Thanks @berndhartzer!
+- CLI: JSON output is now less noisy (#1469). Thanks @michiboo!
+- CLI: k6 doesn't exit when using `iterations` with `stages` (#812).
+- CLI: Mismatch in check counts in the end-of-test summary (#1033).
+- Config: Better validation of `stages` (#875).
+- JS: Rare panics in goja (#867).
+- HTTP: Fix request timeout and wrong context used for pushing metrics (#1260).
+
+
+## Internals
+
+- Switched to Go 1.14 for building and testing k6, bringing some fixes and performance improvements.
+- Code cleanup and formatting. Thanks @thinkerou!
+
+
+## Breaking changes
+
+- Execution config options (`scenarios`, `stages`, `iterations`, `duration`) from "upper" config layers overwrite execution options from "lower" (i.e. CLI flags > environment variables > JS options > JSON options) config layers. For example, the `--iterations` CLI flag will overwrite any execution options set as environment variables (e.g. `K6_DURATION`, `K6_STAGES`, etc.) or script options (`stages: [ /* ... */]`, `execution: { /* ... */ }`, etc. ).
+
+- Using different execution config options on the same level is now a configuration conflict error and will abort the script. For example, executing `k6 run --duration 10s --stages 5s:20 script.js` won't work (closes #812). The only exception is combining `duration` and `iterations`, which will result in a `shared-iterations` executor with the specified non-default `maxDuration` (#1058).
+
+- The k6 REST API for controlling script execution (i.e. the `k6 pause`, `k6 scale` commands) now only works when a `externally-controlled` executor is configured in the `execution` config. The initial pausing of a test (i.e. `k6 run --paused script.js`) still works with all executor types, but once the test is started with `k6 resume` (or the corresponding REST API call), it can't be paused again unless only the `externally-controlled` executor is used.
+
+- Previously, running a script with `k6 run --paused script.js` would have still executed the script's `setup()` function (if it was present and wasn't explicitly disabled with `--no-setup`) and paused immediately after. Now, k6 will pause before it executes `setup()`.
+
+- The `vusMax` / `K6_VUS_MAX` / ` -m` / `--max` option is deprecated - it was previously used for the control of the initialized VUs by the REST API. Since that has now been restricted to the `externally-controlled` executor, the equivalent option there is called `maxVUs`.
+
+- Tests with infinite duration are now only possible via the `externally-controlled` executor.
+
+- Previously, all iterations were interruptible - as soon as the specified `duration` expired, or when VUs were ramped down in a stage, any running iterations were interrupted. Now all executors besides the `externally-controlled` one have a `gracefulStop` period of `30s` by default (closes #898). Additionally, the `ramping-vus` executor has a `gracefulRampDown` parameter that configures the ramp-down grace period. For those periods, no new iterations will be started by the executors, but any currently running iterations will be allowed up to the specified periods to finish their execution.