std library is still considered "unstable" and the sub modules contained in there tend to have their own lifecycle as well. There has been effort to try to mature std to get to a stable version, which means cleaning up lots of things that would detract from long term maintainability.
Re:Deno v1.27
by simlevesque on Thursday October 27, 2022 @05:08PM
(#33364080)
Node.js before v1 (maybe even until v4) was like this. It took like 5 years.
At least for the ones related to trees, it's just a renaming. Below is a link to the PR. When I initially implemented these trees, I chose the names BSTree and RBTree to keep the names short. I'm guessing the person that proposed renaming them did so to make it more obvious what they are.
https://github.com/denoland/deno_std/pull/2400
The standard library is separate from the runtime. It wouldn't break backward compatibility if you were to update. For example, if you were importing RBTree and upgraded Deno to the latest release, it would keep working just fine. You would only really need to switch to using RedBlackTree instead if there was a change made to it that you wanted.
I think the only time you would need to update your standard module imports to be able to use newer versions of the Deno runtime would be if the standard module was depending on runtime APIs that have a breaking change.
> direction has been removed from the collections module in favor of Direction.
> CSVStream has been removed from the encoding module in favor of CsvStream
Hmm I smell an interesting story here. If it's renaming for the sake of renaming then that's kinda dumb and breaks backwards compat for no reason, but presumably there's a better reason somewhere?