These browsers have bugs that occasionally cause typed array comparisons
to pass when they should fail, or vice versa:
* for...in loops sometimes omit keys, such that two typed arrays with
different lengths appear to have the same set of keys.
* Typed arrays sometimes have mulitple undefined keys (which is to say that
the key itself is undefined). Two typed arrays with identical length and
contents can compare unequal because of the spurious undefined keys.)
Those problems could be avoided by comparing keys 0...length-1 rather than
the actual set of exposed keys, but that would be a pretty nasty breaking
change for anyone whose code tacks extra properties onto typed arrays. So
far these bugs haven't been seen in anything newer than FF 128. Since the
affected browsers are all past end of life, the most sensible thing is to
just stop testing against them.
Safari 16 and 17 runners are no longer reliably available in CI. Saucelabs
still provides them, but session creation failures have been frequent for
weeks now. When this has happened in the past, it's been a prelude to
Saucelabs dropping the affected Safari versions altogether.
We could live with retrying ~30-50% of test runs in the hope that things
might improve, but it's probably better to just rip the band-aid off.
This reverts commit e2a7740322.
structuredClone errors in these browsers were a symptom of inavertently
including Error objects in reporter events. In newer browsers,
structuredClone can copy those objects, but it's lossy: if an instance of
an Error subclass is cloned, the result is an instance of Error.
With that fixed, Jasmine is compatible with Safari 16 and FF 102. At least
for now. And keeping them around may provide a way to detect similar bugs.
Safari 15:
* Lacks structuredClone, which is starting to become useful
* Has stack trace quirks that are not well understood, not properly handled
by Jasmine, and can cause problems in Jasmine's own tests
* Is not widely used
* Does not run on any OS that still receives security updates
The Pivotal copyright notice needs to be retained. That's the right
thing to do and the MIT license requires it. However, using it by itself
becomes more obviously incorrect with each passing year since Pivotal
ceased to exist. Moreover, Pivotal hasn't actually been the sole
copyright owner since the first external contribution was merged.
Contributors were not asked to sign a copyright assignment, so they
retain copyright to their contributions.
"Copyright (c) 2008-2019 Pivotal Labs" complies with the terms of the
license and acknowledges Pivotal's outsized role in developing Jasmine.
"Copyright (c) 2008-$YEAR The Jasmine developers" acknowledges all
authors and will remain correct in the future.
The CI status badge mostly just shows whether Saucelabas was flaky
last night. Code Triage was a nice idea but it's attracted at most
one new contributor over 5.5 years.
Node 16 will reach EOL no later than a few months after Jasmine 5 is
released. Experience with Node 12 and Node 14 has shown that our
dependencies, especially dev dependencies, move on from past-EOL Node
versions fairly quickly. That can make it difficult to continue supporting
them. Since long term support for past EOL Node versions is a non-goal and
many users expect that Node versions will only be dropped in major
releases, it's better to drop it in 5.0.
