Here’s a reminder for those who haven’t seen it. Please take a few minutes to fill in the Community Hub Poll as the poll closes in the next few days. Get at it!
Updates from John Blackbourn Toggle Comment Threads | Keyboard Shortcuts
There will be a meeting in #core Slack next Tuesday at 2100 GMT (January 20 2015 21:00 UTC) to discuss feature plugins for WordPress 4.2. Several have been proposed. (If you want to propose one, please do it on that thread.)
In order for a feature plugin to be considered for merge into 4.2, the plugin should already be fairly stable in order to avoid the sort of late development work that we’ve seen with merged feature plugins in recent releases.
A separate meeting to discuss the feature plugin workflow and development process in general will be scheduled at a later date.
Feature plugins for WordPress 4.2 and beyond need to be planned. Let’s get some suggestions together along with their status and who’s working on them.
For each feature plugin that you would like to see considered, either for 4.2 or for a future version, please leave a comment with the following details:
- Current status (eg. idea, planning, early/late development, testing, stable)
- Who’s responsible
- Link to GitHub repo or w.org page, if appropriate
- Whether you’d like the plugin to be considered for 4.2
It’s become apparent that feature plugins need to be at a much more mature stage before they are considered for merge into core. After all, the point of a feature plugin is to build a feature as a plugin and if the plugin never gets merged into core then we’re still left with a fully workable standalone plugin. Any feature plugins which are to be considered for 4.2 need to be at a very mature stage already.
Various issues which came up over the weekend have meant that we’ve decided to delay the release of 4.1 by another 24 hours. The new target release date is Wednesday 17th December. It doesn’t serve anybody well to delay things this late in the day, but it’s essential to ensure the late fixes which have landed in the last few days are well tested.
RC2 will be packaged within the next few hours, once the recent batch of fixes in trunk are merged into the 4.1 branch. Here’s the current list of open tickets in the 4.1 milestone.
We’ll try to fit in a release dry-run meeting today at 17:00 GMT (December 16 2014 17:00 UTC) in #core, depending on the availability of the lead devs.
Drop a comment here if there’s anything specific to RC1 that you think needs discussing.
4.1 was originally due for release today, but a few tickets in the 4.1 milestone have held things up a little. The release candidate will be tagged in time for today’s dev meeting at December 10 2014 21:00 UTC, and the target release date is now
Monday, December 15thTuesday December 16th.
Here’s the agenda for today’s dev meeting:
- Documentation from various make/core posts need to go into the plugin handbook and theme handbook.
- The 4.1 page on the Codex is in progress.
- Eyes on the support forums – the alpha/beta forum has seen almost no activity so we need eyes on the forums as a whole.
- ‘About’ page design – @melchoyce, kelly, @helen #30435
- Plugin developers – update your plugin’s readme files to indicate support for 4.1 once RC1 is released. You’ve tested all your plugins with the beta, yeah?
- Looking for something to do? Tickets reported against trunk needs some continued triaging.
- Status of plugin directory l10n and recommended plugins tab. @stephdau @tellyworth
- Discuss status of l10ns for polyglots.
- Discuss a status update meeting type thing on Sunday.
- Discuss release plan. @nacin
- Any other business.
Background reading: #30335 and the notes on shared term splitting in https://make.wordpress.org/core/2014/11/20/dev-chat-summary-november-19th/.
As part of the work on the taxonomy roadmap in 4.1, shared terms (terms which are shared across more than one taxonomy due to a slug collision) now get split when the term gets updated. The end result being that editing a term in one taxonomy will no longer affect the term in another taxonomy.
Many plugins store term IDs in post meta, options, terms (!), etc, and the side effect of shared term splitting is that these caches can break when the ID of a term they reference changes. Not only that, but the breakage (and the cause) can be invisible to the user and hard to track down if they do notice it.
Following a discussion in #core Slack I’m proposing that shared term splitting is removed from 4.1 and we’ll add it back in for 4.2 and allow a full release cycle to get the word out to developers about the change. I’ll make the final decision during tomorrow’s dev chat.
Thanks in particular to @mboynes for his time spent on this.
(Note that this only affects existing terms; new terms do not get shared since r30240.)
- Splitting terms #30335
- i18n of the plugin directory
- Sidebar behaviour in Twenty Fifteen #30404
- Tweaks to the release schedule:
- Beta 2 tomorrow
- RC back one week?
- Release date unchanged
- String freeze with RC1
- New alpha/beta forum issues
- New Trac issues
- User feedback on the new DFW mode
- Beta tester plugin issues #30405
- Anything else?
Current status: A little over 100 tickets in 4.1 milestone