Correct changelog entry for arrayLimit fix

[kroleg]

• should mention arrayLimit because it's what devs use and arrayLength is internal variable
• should warn that it is a breaking change (example of people reporting behavior change: Query string array parsing behavior changed in version 6.14.1 #537)

[ljharb]

it is absolutely not a breaking change; bugfixes can sometimes break people if they're depending on broken behavior.

[kroleg]

Imo it doesn't matter if behaviour was broken or not. What matters is that this is a significant behaviour change.

Idk but feels like you're being defensive or smth. It's not like i am blaming you for broken apps (it wouldn't make any sense) or asking to release new major version because of it. It's me trying to warn other devs, so people updating to 6.14.1 will be aware that it can break their apps.

[ljharb]

If I agreed it was a breaking change, then I would be compelled to revert it, and publish a new major, and tons of people on v6 would be left vulnerable.

I don't agree it's a breaking change, which is why it's fine to release it in a non-major. EVERY change could break someone's app; that's what tests and lockfiles are for.

[kroleg]

Got you. What wording would allow to warn people but not force you to publish new major? Would you be ok with something like:

- [Fix] ensure arrayLimit applies to `[]` notation as well. 
  WARN: if you handle more than `arrayLimit` (20 by default) items in array query param (i.e. `param[]=a&...param[]=x`) it will be converted to object instead of array

[ljharb]

I don't think any warning is required, personally.

[Edifear]

This change introduced a breaking behavior for our application. We use repeated query params for multi-select filters: ?org=uuid1&org=uuid2&org=uuid3...
This broke our GraphQL queries which expect arrays.
While the fix is technically correct, this is a breaking change for apps relying on the previous behavior

[ljharb]

Again, any change whatsoever could cause an arbitrary application to break. That's not the definition of "breaking change", and if it were, then literally everything would be semver-major every time.

The issue was that your code expected arrays all the time. That's never been a guarantee and arrayLimit should have applied, but incorrectly wasn't. The "failure" is actually a correct exposure of a bug in your own code - you're welcome!