Client Difference Log
API Changes
Added Property bool Studio.CommandBarLocalState
Removed Property LocalizationTable.DevelopmentLanguage
Removed Function LocalizationTable:GetContents
Removed Function LocalizationTable:RemoveKey
Removed Function LocalizationTable:SetContents
Removed Function LocalizationTable:SetEntry
(Click here for a syntax highlighted version!)
Iāve ran into issues before where the Humanoid State didnāt correspond to the replicated physics state, such as when the Jump state ended and was replicated to other clients before the character had visually landed a jump/fall on the receiving client. Iām curious to see if and how this change might impact that.
Looks like this broke rojoās LocalizationTable support by accident.
I hope thatās still being maintained actively 
(cc @ContextLost)
EDIT: There is a pull request to patch this error. Since Roblox owns the project now, an engineer will need to review this. Can someone take a look?
What does CommandBarLocalState do specifically? Is it something to do with the new or currernt output or possibly the plugin section, it sounds familiar to something for plugins. Iām kind of interested in what it does specifically, might learn more about it if I get more information.
Luau got smarter and I mean smarter when I or other developers when doing a.b() than a:b(), looks like things will get better with some scripting practice when this becomes live. 
Question that I had in mind: How much faster or how fast will it track whenever using a.b() or a:b()? Something that I had in mind and thinking about. 
Humanoid.RequiresNeck seems interesting to use and look at whenever I work with humanoids, although it would be interesting whenever .RequiresNeck is removed/destroyed, it would cause the humanoid to die but thatās just something I would have fun doing.
Ragdoll states I would say become easier and safe to control and command; with the replication of humanoid states, it seems nice to add to humanoids for timing and the network but I would see some flaws with this in the future, just an if moment.
I havenāt confirmed this yet, but @Anaminus guessed that it keeps declared local variables alive.
Right now you canāt issue these two commands separately:
> local a = 0
> print(a)
The local variable a falls out of scope in the next command execution, so a is nil in print(a).
Enabling CommandBarLocalState forces the scope to be kept open for any previously defined local variables.
Is this related at all to the issue where players can get frozen indefinitely with ClientPauseMode on lower-end devices? i.e:
(StreamingEnabled, ClientPhysicsPause mode, 32 Min Radius, 1280 Target Radius)
Changed the way Humanoid state replicates from the network owner of the Humanoid. Currently uses physics replication, will use property replication. This may change the timing of state change events for remotely owned Humanoids.
This seems potentially breaking if developers are already accounting for weird behavior. I do a lot of weird custom character stuff, is there a way to test this before itās live?
I hope someone takes a look. I tried my best to replicate it based on what I saw in the older versions. Not sure how they manage to break their own tool without realizing it, but hey, Roblox does some weird things.
Also, given Luauās āreadability is betterā thing, why would they even bother optimizing str:foo()?
Thank god for this. This was an annoying bug.
I mean Lua gave strings a metatable for a reason, so we could call them directly on the strings via __index. It is pretty useful, although if you need all the performance you can get you should do what is recommended, which is directly accessing them from string
Changed the way Humanoid state replicates from the network owner of the Humanoid. Currently uses physics replication, will use property replication. This may change the timing of state change events for remotely owned Humanoids.
Does this mean more consistent Humanoid event firing? 
Added
Humanoid.RequiresNeck. If disabled the Humanoid will not die when its Neck joint is removed. This should make temporary ragdoll states easier.
Yooooo! This has been a long-time coming.
Ah, so thatās what it does basically, would like a documentation on what else it could do instead of making declared localsā alive.
Thatās something helpful and useful whenever someone and I is/are scripting, maybe Anaminus or maybe Zeuxcg could have more information on CommandBarLocalState? Thanks for that. 
Might actually have something to do with debugging. Thereās a string in the Studio executable that says the following:
Command bar operates on local state at breakpoint
Much more exciting, I think.
Sorry for my ignorance, but whatās new in this version, since all status are āPendingā?
New features / bugfixes are getting turned on every day. Stuff just shows up in the changelog when the code for it first shows up in the desktop client / studio, from there it will be anywhere from a couple days to a few weeks before it gets turned on.
When significant new features are fully stable / available there will be an actual announcement post in the section about them.
Is there a more detailed log of all the corrections that were made between one version and another? I already had a question about a fix made to the Expressive Output Window, which was not announced and I only discovered, by chance, much later.
Itās mostly a side effect for some changes to vectors that are still in development, but it happens to only apply to strings for now.
The only official avenue is the announcement posts.
The reason that there is no more detailed log provided is that sometimes minor features/bugfixes are turned on but have to be rolled back, and some features consist of a many individual sub-features which may be turned on individually one at a time. Sometimes features are turned on for different platforms at different times too. This means that a āfully accurateā log of all the changes happening would be very dense and too confusing to be useful to most readers.
If youāre looking for an unofficial one, check out my client tracker:
I know that my opinion will not change anything in the Release Notes policyā¦ but allow me to disagree.
I have been working with IT for almost 40 years. And one of the things that most impact a version release is a wide and transparent disclosure of everything that has changed. And this is nothing new. In fact, Roblox is one of the few cases I know that chooses to keep users uninformed about a detailed release note. I donāt know if this is on purpose, or simply because Roblox does not have adequate version control systems, which require the programmer to detail what has been corrected (a text in a technical / internal way and another text for users / public).
This would not be difficult to do and it is in fact a serious policy, followed by many serious companies. Detailing what has been modified is not expensive, it is not laborious, it is just a matter of methods and habits. But in the end, everyone wins with this more open communication.
In the current format, as I mentioned in the example of the Expressive Output Window, the user has to discover for himself what has been changed. This is not good.