Dev Chat Summary: March 7th (4.9.5 week 5)

This post summarizes the dev chat meeting from March 7th (agenda, Slack archive).

4.9.5 planning

  • @audrasjb and @danieltj to lead bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrubs every Tuesday from 20:00 to 21:00 UTC
  • Planned release schedule:
    • BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.: 03/20
    • RC: 03/27
    • Expected release date: 04/03
  • Looking to move some 5.0 `good-first-bug` labelled tickets to 4.9.5 if they are already committed, self-contained, can be back-ported cleanly before milestoning, and don’t introduce any unintended backcompat issues

Definition of what’s included in minor releases && GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ updates

  • @jbpaul17: Suggestion to expand what can go into minor releases and allow new files to be introduced as this could benefit projects being able to ship in a minor versus waiting for a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope./5.0 (e.g., serve happy, debug screen, on boarding improvements, GDPR compliance tools)
  • @jbpaul17: Question as to cons for doing so (e.g., breaking auto-updates) and whether they’re unsolvable technical problems or historical blockers that haven’t been researched recently and could potentially be resolved
  • Previous discussion on this topic related to inline docs
    • “Every extra file adds a significant amount of KB to the package, which adds up pretty quickly. This not only stretches the wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ load balancers (when suddenly millions of sites are updating within an hour), but also each individual site, which must download the ZIP, which takes time (partial builds made things, on many shared servers, go from minutes to seconds) and introduces lots of possibilities of download failures, and thus sites needing to retry later (and wait longer) to get patched.”
  • Prior comment that although it’s a little inconvenient, it’s a handy line in the sand for backporting to prevent new files
  • @joemcgill: Important to get input from people familiar with and have access to the infrastructure and historical data about releases
  • Side conversation on altering version numbering scheme such that next major could be 4.10.0 and allow non-Gutenberg projects to land in a major release while Gutenberg can still have the 5.0 version number; alternative to switching to semantic versioning is pushing Gutenberg back to 5.1
  • @joemcgill: Important to clarify what we’re trying to solve: trying to release some new features that are blocked while we wait for Gutenberg/5.0. Suggestion: discuss the specific features and why they’re worth including in a minor and figure out the technical blockers to make that happen
  • @xkon: GDPR work is trying to avoid shipping with Gutenberg to ensure user-stress levels are low for these respective updates; in an ideal world GDPR should land before May 25th
  • @joemcgill: Helpful to understand the roadmap for 5.0 timelines to know if we should squeeze something in a minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality. or do a vanity 4.9.10 major release
  • @matveb: Gutenberg plan is still tentatively April
  • @peterwilsoncc: Pushing new files into minors would require two releases:
    • 1 to update auto updates
    • 2 to update and include the new files for GDPR, serve happy, etc.
  • @sergey: precedent of adding new functions to existing files in a minor branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". where they’re in separate files on trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., same could apply for GDPR/etc.
  • @joemcgill: restating the problem… We have some features ready for release but are blocked by historical constraints on our minor release process, meanwhile we have no clear sense of when the next major is going to be ready because it’s tied to Gutenberg
    • Option 1: Change the constraints on a minor release and add the features. This needs input from infrastructure people
    • Option 2: Do a major release before Gutenberg is ready if we need to
    • Option 3: Wait for Gutenberg to be ready
  • Gutenberg team looking for more help in getting it ready for the path to merge proposal, getting a promo notice in a release to help increase testing
  • @azaozz: GDPR tools cannot wait very long. Will need to be out end of April, early May the latest
  • Gutenberg work divided into “feature complete”, “merge proposal” (things we definitely need), and “5.0
  • Gutenberg areas that need attention for 5.0 merge:
    • APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. tasks need owners.
    • All coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. issues should have corresponding tickets.
    • JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. packages integration can be a topic for the core-js chats.
    • Gutenberg repo needs help with triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. and fixing bugs.
    • Documentation and coding standard updates.
    • AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) needs to be improved
  • Various Gutenberg-related tasks could use help and don’t have to wait for merge proposal:
    • Various REST API tasks that can be done now in parallel
    • Core changes
    • New endpoints and infrastructure plans
    • How would inclusion of Gutenberg/JS packages work
  • Gutenberg team would like to see how integration with truck would work as early as possible, aiming for April for an initial merge/first beta (not actual 5.0 release)
  • Gutenberg team needs more component and lead developers focus and feedback

Next meeting

The next meeting will take place on March 14, 2018 at 21:00 UTC / March 14, 2018 at 21:00 UTC in the #core SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-5, #core, #dev-chat, #summary