Breaking changes on clickability and date-times retrieved from page URL

Hi all - Sending an update that the revert is now live.

Is working now, thank you

I completely agree.

I’m struggling to understand why it would it be acceptable to knowingly risk breaking any user’s app.

I’d be curious to know how that’s envisioned to work. Surely it wouldn’t be through the forum.

I agree with @Jici and @ed727 that if it’s a breaking change, it should be versioned. Period.

I would also like to propose that when a breaking change is available thorough a new Bubble version that the “gift” icon in the menu bar of the editor turn red (or flash or use some other conspicuous visual indicator) to grab the user’s attention right in the editor where and when it matters until the user acknowledges they’ve seen the notice by clicking a link or something.

I mean, the forum is great, but the editor seems like the most appropriate (and dare I say obvious) place to notify ALL Bubble users of this kind of thing.

@grace.hong From the behavior I observed, particularly regarding dates/times, this update seemed like it still needed lots of work before being rolled into a new version. Is the team aware of this or are they under the impression the changes that were deployed last night will simply be rolled into a new Bubble version as is?

Hey all -

We’ll be releasing the date-times change in a new Bubble version next week. As for the clickability change, we want to investigate further how users are currently using this feature before putting the change in a Bubble version. There seem to be use cases that we didn’t take into account, in terms of how users are controlling workflows and mouse pointing.

Thank you @Jici, @ed727, @sudsy for the feedback; I really appreciate it. Looking back, I think I was a bit unclear when I explained how we assess whether we should make a change. I meant to reference changes more broadly, which can encompass super small bug fixes that correct behavior (for instance, the rounding on floats we released a few days back). These have implications for our users, but the intent in releasing them is that we feel confident that ultimately there’s a net benefit for users as these changes correct behavior. Fixes as small as these could be perceived as breaking changes because they are indeed changing behavior, and in that case, I think you all bring up a great point – to what extent we feel a change should be versioned versus deployed immediately.

Regardless, we’re having a live discussion as a team next week reflecting on how we should best move forward and how we can use this as a learning opportunity. I’d be happy to share your suggestions and concerns, as well as what we conclude from the meeting.

Thanks for flagging this! We’ll take a look at your app before rolling the code into a new version to double check if anything’s amiss. If there’s anything else you encounter, I’d recommend submitting a bug report.

The change to the URL behavior seemed to propagate issues all the way to the way standard dates and times are displayed. For example on this page: Scoreboard 2/14/22 | Takeside News Every single game time was completely wrong once the update was pushed.

Additionally navigating between days would sometimes skip days and sometimes take 2 clicks to change the day. I would heavily recommend not pushing the date-times changes with this update. Every single element on my site was affected.

Hey @grace.hong, is this coming back? I actually prefer the new (intended) behavior. It fixed parts of my site as mentioned here. My only complaint was that the roll-out didn’t give some folks time to identify and fix issues.

Hey @sudsy, thanks for the follow-up. We want to investigate a bit further into how users interacted with that feature to see if we need to modify anything in the original change, and I cannot guarantee that this will be on our immediate roadmap. I will keep you updated when we do roll it out though!