WordPress 6.2 Delayed to March 29 Due to Bug With Date Formats

WordPress 6.2 was scheduled for release today, but contributors discovered a bug with date formats during the 24-hour freeze that they believe could have a significant impact on functionality like bookings, date permalinks, and e-commerce stores.

The decision was made this morning to delay with a consensus to apply a revert and release a silent 6.2 RC5 with the fix. WordPress 6.2 Core Tech Co-Lead Tonya Mork proposed reverting as the impact seemed too widespread to risk releasing today with a fix delayed to a minor release.

“I don’t think this can wait until 6.2.1 given that this isn’t just some text that won’t bold, but something that will have quite a big impact (including stress/financial) on site owners and staff managing bookings and such,” 6.2 Core Triage Lead Colin Stewart said.

WordPress Core Committer Jonathan Desrosiers also weighed in on the issue in favor of a revert and silent RC5.

“I also think that [it’s] impossible to anticipate the full impact of this change,” Desrosiers said. “This definitely illustrates the importance of accompanying even the smallest changes with appropriate tests. We owe this due diligence to our users.

“If we release the issue with 6.2 we could have a much greater problem on our hands. It’s not something that would not be easy to recognize or understand for the large majority of users, and it’s nearly impossible for Core to ‘auto-fix’ any occurrences of the bug  in a future minor release. We also should really avoid having to include fixes like that anyway as they’re just a huge maintenance burden/technical debt.”

Contributors in the discussion this morning agreed that knowingly shipping broken code just to keep the schedule would be a wrong move and that shipping a fix today could introduce additional problems. An announcement will be posted to the Make/Core, followed by the 6.2 RC5 release, which will restart the 24-hour clock ahead of the official 6.2 release tomorrow.

9

9 responses to “WordPress 6.2 Delayed to March 29 Due to Bug With Date Formats”

  1. Better to hold until sure than to rush to meet an arbitrary date. Releases come out to quickly for my taste, anyway—more time to adapt to the new features before another new release comes out is helpful to those of us who don’t do this full time.

  2. I never put a .0 release of any product into production if I can possibly avoid it, however this one includes a fix for a bug I found so I was hanging out for it. The decision to postpone though is definitely the correct one IMHO; why would you knowingly publish incorrect code?

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.