Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Notes for v0.54.0 #3949

Open
wants to merge 28 commits into
base: master
Choose a base branch
from
Open

Release Notes for v0.54.0 #3949

wants to merge 28 commits into from

Conversation

olegbespalov
Copy link
Contributor

@olegbespalov olegbespalov commented Sep 12, 2024

What?

A release notes.

Why?

It's part of the release

Checklist

  • I have performed a self-review of my code.
  • I have added tests for my changes.
  • I have run linter locally (make lint) and all checks pass.
  • I have run tests locally (make tests) and all tests pass.
  • I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

@olegbespalov olegbespalov changed the title Release v0.54.0 Release Notes for v0.54.0 Sep 12, 2024
@olegbespalov olegbespalov self-assigned this Sep 12, 2024
@olegbespalov olegbespalov added this to the v0.54.0 milestone Sep 12, 2024
@olegbespalov olegbespalov marked this pull request as ready for review September 13, 2024 13:08
release notes/v0.54.0.md Outdated Show resolved Hide resolved
release notes/v0.54.0.md Outdated Show resolved Hide resolved
release notes/v0.54.0.md Outdated Show resolved Hide resolved
release notes/v0.54.0.md Outdated Show resolved Hide resolved
Copy link
Contributor

@heitortsergent heitortsergent left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a lot of comments but they're mostly small edits. 🙇

k6 `v0.54.0` is here 🎉! This release includes:

- A new experimental CSV module
- new ECMAScript features
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- new ECMAScript features
- New ECMAScript features


## Breaking changes

- [#3913](https://github.com/grafana/k6/pull/3913) changes mapping of the Golang's `math/big.Int` type to `bigint` type in k6.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [#3913](https://github.com/grafana/k6/pull/3913) changes mapping of the Golang's `math/big.Int` type to `bigint` type in k6.
- [#3913](https://github.com/grafana/k6/pull/3913) changes the mapping of Golang's `math/big.Int` type to `bigint` type in k6.


- [#3913](https://github.com/grafana/k6/pull/3913) changes mapping of the Golang's `math/big.Int` type to `bigint` type in k6.
- [#3922](https://github.com/grafana/k6/pull/3922) removes `lib.Min` and `lib.Max` from k6's Go API, which could affect custom extensions that rely on these functions.
- [#3838](https://github.com/grafana/k6/pull/3838) remove `k6/experimental/timers` - they are now available globally and no import is needed.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [#3838](https://github.com/grafana/k6/pull/3838) remove `k6/experimental/timers` - they are now available globally and no import is needed.
- [#3838](https://github.com/grafana/k6/pull/3838) removes `k6/experimental/timers` - they are now available globally and no import is needed.

- [#3913](https://github.com/grafana/k6/pull/3913) changes mapping of the Golang's `math/big.Int` type to `bigint` type in k6.
- [#3922](https://github.com/grafana/k6/pull/3922) removes `lib.Min` and `lib.Max` from k6's Go API, which could affect custom extensions that rely on these functions.
- [#3838](https://github.com/grafana/k6/pull/3838) remove `k6/experimental/timers` - they are now available globally and no import is needed.
- [#3944](https://github.com/grafana/k6/pull/3844) updates to `k6/experimental/websockets` made the default to binaryType to be `"blob"` as per the specification. Previously it was not set by default and required to be set and before that it was `"arraybuffer"`. With this change `k6/experimental/websockets` is now compliant with the specification.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- [#3944](https://github.com/grafana/k6/pull/3844) updates to `k6/experimental/websockets` made the default to binaryType to be `"blob"` as per the specification. Previously it was not set by default and required to be set and before that it was `"arraybuffer"`. With this change `k6/experimental/websockets` is now compliant with the specification.
- [#3944](https://github.com/grafana/k6/pull/3844) updates to `k6/experimental/websockets` made the `binaryType` default value equal to `"blob"`, as per the specification. In previous versions, the default value was not set, or it was equal to `"arraybuffer"`. With this change, `k6/experimental/websockets` is now compliant with the specification.

I reworded it a bit to make it easier to read, but I'm wondering if we could make it more concise and just say:

"- #3944 updates to k6/experimental/websockets made the binaryType default value equal to "blob". With this change, k6/experimental/websockets is now compliant with the specification."

What do you think?

Comment on lines +20 to +22
As part of Grafana Labs, k6 got renamed to Grafana k6, instead of k6.io. We also had a purple icon making a bit jarring next to all the other orange-y ones.

As such in this release we also got a new logo and the terminal banner has been redesigned to more closely match the current branding.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
As part of Grafana Labs, k6 got renamed to Grafana k6, instead of k6.io. We also had a purple icon making a bit jarring next to all the other orange-y ones.
As such in this release we also got a new logo and the terminal banner has been redesigned to more closely match the current branding.
As part of joining Grafana Labs in 2021, k6 was renamed to Grafana k6. The original k6 logo and branding was purple, which didn't fit very well next to the Grafana Labs orange logo and all its other products.
In this release, we have a new logo in a new color, and the terminal banner has been redesigned to match the current branding more closely.

});
```

To address this limitation, we've added a version of the `check` function to [jslib.k6.io](https://jslib.k6.io/) that makes working with `async`/`await` more ergonomic. The `check` function is a drop-in replacement for the built-in check, with added support for async code. Any `Promise`s will be awaited, and the result is reported once the operation has been completed:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
To address this limitation, we've added a version of the `check` function to [jslib.k6.io](https://jslib.k6.io/) that makes working with `async`/`await` more ergonomic. The `check` function is a drop-in replacement for the built-in check, with added support for async code. Any `Promise`s will be awaited, and the result is reported once the operation has been completed:
To address this limitation, we've added a version of the `check` function to [jslib.k6.io](https://jslib.k6.io/) that makes working with `async`/`await` simpler. The `check` function is a drop-in replacement for the built-in check, with added support for async code. Any `Promise`s will be awaited, and the result is reported once the operation has been completed:

Comment on lines +243 to +249
### Support ArrayBufferViews in send for `k6/experimental/websockets` [#3944](https://github.com/grafana/k6/pull/3844)

As part of making `k6/experimental/websockets` complaint with the [WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket) it now support Uint8Array and other ArrayBufferViews directly as arguments to `send`, instead of having to specifically provide their `buffer`.

This should make it more compliant with libraries that use WebSocket API.

Thanks to @pixeldrew for [reporting](https://github.com/grafana/xk6-websockets/issues/75) this :bow:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Support ArrayBufferViews in send for `k6/experimental/websockets` [#3944](https://github.com/grafana/k6/pull/3844)
As part of making `k6/experimental/websockets` complaint with the [WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket) it now support Uint8Array and other ArrayBufferViews directly as arguments to `send`, instead of having to specifically provide their `buffer`.
This should make it more compliant with libraries that use WebSocket API.
Thanks to @pixeldrew for [reporting](https://github.com/grafana/xk6-websockets/issues/75) this :bow:
### Support ArrayBufferViews in `send` for `k6/experimental/websockets` [#3944](https://github.com/grafana/k6/pull/3844)
As part of making `k6/experimental/websockets` compliant with the [WebSocket API](https://developer.mozilla.org/en-US/docs/Web/API/WebSocket), it now supports Uint8Array and other ArrayBufferViews directly as arguments to `send`, instead of having to specifically provide their `buffer`.
This should make the module more compliant with libraries that use the WebSocket API.
Thanks to @pixeldrew for [reporting](https://github.com/grafana/xk6-websockets/issues/75) this. :bow:

Comment on lines +254 to +258
As part of working on k6 over the years we have many times wondered if given features is used or if this strange corner case behavior is being used.

We usually made guesses or tried to extrapolate from experience on issues we see or maybe even cloud customers. This unfortunately isn't always easy or possible at all and definitely is very skewed. As such we usually also added warning messages to thing we intend on breaking to let people know and ask them to report if they see problems. This usually see very little activity especially before we make the changes.

This also only works for things we want to remove, but doesn't help us know if people use new functionality at all or if there are patterns that we do not expect.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
As part of working on k6 over the years we have many times wondered if given features is used or if this strange corner case behavior is being used.
We usually made guesses or tried to extrapolate from experience on issues we see or maybe even cloud customers. This unfortunately isn't always easy or possible at all and definitely is very skewed. As such we usually also added warning messages to thing we intend on breaking to let people know and ask them to report if they see problems. This usually see very little activity especially before we make the changes.
This also only works for things we want to remove, but doesn't help us know if people use new functionality at all or if there are patterns that we do not expect.
As part of working on k6 over the years, we have often wondered if users use certain features or if they see a strange corner case behavior.
We have usually made guesses or tried to extrapolate from experience on issues we see. Unfortunately, this isn't always easy or possible, and it's definitely very skewed. As such, we usually also add warning messages to things we intend to break to inform people and ask them to report problems. But we usually see very little activity, especially before we make changes.
This also only works for things we want to remove, and it doesn't help us know if people use new functionality at all or if there are patterns we don't expect.

Comment on lines +260 to +268
While k6 has been collecting usage for a while it is usually very surface level stuff, such as how many VUs were run, k6 version, what *internal* modules were loaded and such.

And the system for this was very rigid requiring usually a lot of work to add simple stuff, like if someone used the `require` function.

This has been reworked to make this a lot easier to do and a few new usage reports have been added:
- when cloud is used it will also tell us which test run it is. We already have most if not actually more of the information reported through metrics and it being ran in the cloud. But this will also help us filter cloud from not cloud runs easier and also potentially tell cloud users that they are using experimental modules that are to be removed soon.
- number of files parsed as well as number of ts files parsed. This will be useful both in us figuring out if people use small projects or bigger ones as well as if ts file support is being used.
- usage of `require`. Now that we have ESM native support, using `require` and CommonJS adds complexity. It is interesting to us whether removing this in the future - likely years, given it support in other runtimes, is even feasable.
- usage of `global`. This for help us decide if we can [drop compatility-mode](https://github.com/grafana/k6/issues/3864) differences or even the whole concept of them.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
While k6 has been collecting usage for a while it is usually very surface level stuff, such as how many VUs were run, k6 version, what *internal* modules were loaded and such.
And the system for this was very rigid requiring usually a lot of work to add simple stuff, like if someone used the `require` function.
This has been reworked to make this a lot easier to do and a few new usage reports have been added:
- when cloud is used it will also tell us which test run it is. We already have most if not actually more of the information reported through metrics and it being ran in the cloud. But this will also help us filter cloud from not cloud runs easier and also potentially tell cloud users that they are using experimental modules that are to be removed soon.
- number of files parsed as well as number of ts files parsed. This will be useful both in us figuring out if people use small projects or bigger ones as well as if ts file support is being used.
- usage of `require`. Now that we have ESM native support, using `require` and CommonJS adds complexity. It is interesting to us whether removing this in the future - likely years, given it support in other runtimes, is even feasable.
- usage of `global`. This for help us decide if we can [drop compatility-mode](https://github.com/grafana/k6/issues/3864) differences or even the whole concept of them.
While k6 has been collecting usage for a while, they're surface-level things, such as how many VUs were run, the k6 version, or which *internal* modules were loaded. The system for this was also very rigid, requiring a lot of work to add simple things, such as if someone used the `require` function.
This process has been reworked to make things easier, and a few new usage reports have been added:
- When Grafana Cloud is used, it will also tell us which test run it is. We already have most of the information reported through metrics and from the test being executed in the cloud. But this will help us filter cloud test runs from local runs and potentially warn cloud users if they're using experimental modules that will be removed.
- The number of files parsed, as well as the number of .ts files parsed. This will help us understand if people use small or big projects and if TypeScript support is being used.
- Usage of `require`. Now that we have ESM native support, using `require` and CommonJS adds complexity. It's interesting to us whether removing this in the future - likely years, given its support in other runtimes, is feasible.
- Usage of `global`. This will help us decide if we can [drop compatibility-mode](https://github.com/grafana/k6/issues/3864) differences or even the whole concept.

Comment on lines +302 to +304
In version 0.52.0, the browser module [transitioned](https://github.com/grafana/k6/pull/3793) from the experimental phase to stable. The new module is more stable and has a [full Async API](https://github.com/grafana/xk6-browser/pull/1374). To ensure your scripts continue working, you must migrate to the new `k6/browser` module and discontinue using the previous `k6/experimental/browser` module. Please see [the migration guide](https://grafana.com/docs/k6/latest/using-k6-browser/migrating-to-k6-v0-52/) for more details.

_Discussion of future plans_
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In version 0.52.0, the browser module [transitioned](https://github.com/grafana/k6/pull/3793) from the experimental phase to stable. The new module is more stable and has a [full Async API](https://github.com/grafana/xk6-browser/pull/1374). To ensure your scripts continue working, you must migrate to the new `k6/browser` module and discontinue using the previous `k6/experimental/browser` module. Please see [the migration guide](https://grafana.com/docs/k6/latest/using-k6-browser/migrating-to-k6-v0-52/) for more details.
_Discussion of future plans_
In version 0.52.0, the browser module [transitioned](https://github.com/grafana/k6/pull/3793) from experimental to stable. The new module is more stable and has a [full Async API](https://github.com/grafana/xk6-browser/pull/1374). To ensure your scripts continue working, you must migrate to the new `k6/browser` module and discontinue using the previous `k6/experimental/browser` module. Please see [the migration guide](https://grafana.com/docs/k6/latest/using-k6-browser/migrating-to-k6-v0-52/) for more details.

Comment on lines +9 to +10
- [#3913](https://github.com/grafana/k6/pull/3913) changes mapping of the Golang's `math/big.Int` type to `bigint` type in k6.
- [#3922](https://github.com/grafana/k6/pull/3922) removes `lib.Min` and `lib.Max` from k6's Go API, which could affect custom extensions that rely on these functions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do these two items require any docs updates? 🤔


</details>

### New `k6 cloud upload` command for uploading test files to the cloud [`#3906`](https://github.com/grafana/k6/pull/3906)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we still need a docs PR for this update.


Thank you, @lzakharov!

#### New argument `meta` for gRPC's stream callbacks
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this might need a docs update as well.


Check out [the `check` utility function's documentation](https://grafana.com/docs/k6/latest/javascript-api/jslib/utils/check/) for more information on how to use it.

### Support ArrayBufferViews in send for `k6/experimental/websockets` [#3944](https://github.com/grafana/k6/pull/3844)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this require a docs update? 🤔

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

already pushed grafana/k6-docs@1f74a07 ... as main turned out to not be protected from direct pushes. It is now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants