Client Difference Log
API Changes
Added Enum CreateOutfitFailure
Added EnumItem CreateOutfitFailure.InvalidName : 1
Added EnumItem CreateOutfitFailure.OutfitLimitReached : 2
Added EnumItem CreateOutfitFailure.Other : 3
Added EnumItem DraggerCoordinateSpace.World : 1
Changed the parameters of Function PhysicsService:IkSolve
from: (Instance part, CFrame target, float translateStiffness, float rotateStiffness)
to: (Class<BasePart> part, CFrame target, float translateStiffness, float rotateStiffness)
Changed the parameters of Function PhysicsService:LocalIkSolve
from: (Instance part, CFrame target, float translateStiffness, float rotateStiffness)
to: (Class<BasePart> part, CFrame target, float translateStiffness, float rotateStiffness)
Changed the parameters of Function WorldRoot:IKMoveTo
from: (Instance part, CFrame target, float translateStiffness = 0.5, float rotateStiffness = 0.5, Enum<IKCollisionsMode> collisionsMode = "OtherMechanismsAnchored")
to: (Class<BasePart> part, CFrame target, float translateStiffness = 0.5, float rotateStiffness = 0.5, Enum<IKCollisionsMode> collisionsMode = "OtherMechanismsAnchored")
Changed the return-type of Function Instance:GetActor
from: Instance
to: Class<Actor>
Changed the return-type of Function Player:GetMouse
from: Instance
to: Class<Mouse>
Changed the parameters of Event AvatarEditorService.PromptCreateOutfitCompleted
from: (Enum<AvatarPromptResult> result)
to: (Enum<AvatarPromptResult> result, Variant failureType)
Changed the parameters of Event ClickDetector.MouseClick
from: (Instance playerWhoClicked)
to: (Class<Player> playerWhoClicked)
Changed the parameters of Event ClickDetector.MouseHoverEnter
from: (Instance playerWhoHovered)
to: (Class<Player> playerWhoHovered)
Changed the parameters of Event ClickDetector.MouseHoverLeave
from: (Instance playerWhoHovered)
to: (Class<Player> playerWhoHovered)
Changed the parameters of Event ClickDetector.RightMouseClick
from: (Instance playerWhoClicked)
to: (Class<Player> playerWhoClicked)
Changed the parameters of Event ProximityPrompt.PromptButtonHoldBegan
from: (Instance playerWhoTriggered)
to: (Class<Player> playerWhoTriggered)
Changed the parameters of Event ProximityPrompt.PromptButtonHoldEnded
from: (Instance playerWhoTriggered)
to: (Class<Player> playerWhoTriggered)
Changed the parameters of Event ProximityPrompt.TriggerEnded
from: (Instance playerWhoTriggered)
to: (Class<Player> playerWhoTriggered)
Changed the parameters of Event ProximityPrompt.Triggered
from: (Instance playerWhoTriggered)
to: (Class<Player> playerWhoTriggered)
Changed the parameters of Event ProximityPromptService.PromptButtonHoldBegan
from: (Instance prompt, Instance playerWhoTriggered)
to: (Class<ProximityPrompt> prompt, Class<Player> playerWhoTriggered)
Changed the parameters of Event ProximityPromptService.PromptButtonHoldEnded
from: (Instance prompt, Instance playerWhoTriggered)
to: (Class<ProximityPrompt> prompt, Class<Player> playerWhoTriggered)
Changed the parameters of Event ProximityPromptService.PromptHidden
from: (Instance prompt)
to: (Class<ProximityPrompt> prompt)
Changed the parameters of Event ProximityPromptService.PromptShown
from: (Instance prompt, Enum<ProximityPromptInputType> inputType)
to: (Class<ProximityPrompt> prompt, Enum<ProximityPromptInputType> inputType)
Changed the parameters of Event ProximityPromptService.PromptTriggerEnded
from: (Instance prompt, Instance playerWhoTriggered)
to: (Class<ProximityPrompt> prompt, Class<Player> playerWhoTriggered)
Changed the parameters of Event ProximityPromptService.PromptTriggered
from: (Instance prompt, Instance playerWhoTriggered)
to: (Class<ProximityPrompt> prompt, Class<Player> playerWhoTriggered)
Removed EnumItem DraggerCoordinateSpace.Constant
(Click here for a syntax highlighted version!)
What exactly does it mean for an item to have a status of “Pending”? For most of these “Release Notes”, it seems ~75% of the items are “Pending”. Not to be a negative nevan, but if they’re not yet usable, in what way are they “Released”? Even going back 100 release notes ago, there’s still >50% “Pending”. I appreciate the updates, but it’s kind of disappointing when I see something useful and then realize it’s “Pending” and may remain that way for weeks if not months.
You do realize release notes are not live status updates on what features are enabled in studio, right? Not sure what would make you think they were. It tell you what is released and what is pending in that studio version. Pending most likely meaning it’s disabled via flag.
“most likely”, meaning you don’t know. Hence why I asked what it means for it to be pending.
I know these aren’t big feature announcements, but they are posted on the devforum / devhub; that means these posts are for the benefit of developers. Therefore, I should reasonably expect release notes to benefit me. I also think it’s reasonable to expect that when something is “released”, it will be enabled at some point in the near future (especially if it’s just initially “disabled via flag” like you say).
I just checked the earliest release notes on the devhub (#327); it was posted February 2018 and currently has 5/16 items “Live” while the rest are “Pending”. That’s ~69% of that “release” that is not currently live. Out of the 11 pending items, 4 are bug fixes. I would expect a bug fix like “Fixed Server/Player launch on Mac” to be enabled before 3 years passes.
However, I could be misunderstanding how the release notes work. Maybe they don’t update older release notes. Maybe pending means it can’t be confirmed as being 100% working. Maybe some of the older pending items are superseded by newer release items. I don’t know. Hence why I asked
You are entirely misunderstanding how release notes work. Again, as I said in my previous post, release notes are not live status updates about what’s enabled RIGHT NOW and what isn’t. It tells you what was enabled AT THE TIME. Flags which turn off certain features are typically turned on within a few days to a few weeks, but again, the release notes are still going to say “pending” because they are not live status updates.
I hope my explanation was clearer this time.
I mean, I don’t think that’s an unreasonable expectation at all. They were even intended to work like that, but it turns out that in reality it’s not as simple as “live / not live” (may be live on some platforms but not others, may go live and then get rolled back, may be live but only under a beta, etc etc) so that didn’t pan out and now they’re just never updated.
EDIT: It turns out that there is an automated process that attempts to update them, but is failing in many cases, it’s being looked into now.
Never knew that’s how they were intended. As you say, it’s not as simple as “live / not live” considering how Roblox updates roll out across all supported platforms. Perhaps sometime in the future there might be a more detailed release notes page that specifies which platforms a feature is or is not live on and can hook into specific FFlags.
Not that it’s an unreasonable expectation, it certainly is. I’d much prefer it if they did so I wouldn’t need to check FFlags manually. But rather because of the fact that release notes from months and years ago still list long-released features as “pending” it should be obvious that they don’t reflect the current status of the feature.
I think release notes as a whole could work better if there was an effort on the engineering side to provide discrete and consistent tickets that describe the FFlags involved in the public rollout of a change, including renames that require an increment to the flag name.
It would have to be tied into the shipping lifecycle of the change, with automated checks and balances to measure the completion of the ticket. Then this could all be reflected back to the release note to ensure there’s no confusion over the pending/live statuses.
I reckon this is easier said than done given workplace politics, but hopefully one of these days we’ll see the DevHub get some much needed quality of life upgrades.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.