WordPress 4.9.5 was released a couple of weeks ago, at the scheduled time and without known issues.
We (@audrasjb and @danieltj) had the pleasure to co-lead this minor 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. of the CMS, with @sergey‘s invaluable help as deputy and @jbpaul17’s mentorship. For this release, we were two co-leaders, contributing to the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for a short time, and none of us had core committer A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component. status. Thank you all again for trusting us for this task.
Below you will find some feedback and tips we wanted to share with you and we hope this will encourage others to get involved in such an adventure.
To lead a WordPress release, you don’t have to be a core committer,
you have to deeply care about the WordPress open-source project.
Initially, we wondered how the two of us could claim to run a WordPress release without commit access.
In fact, there are many tasks that are not related to the commit action itself, but require a good knowledge of the ecosystem, the people and teams involved and how the release process works. Here are some examples of tasks to do:
- Triage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors.: sorting tickets and status update. This is a very time consuming task, because you have to dive into each ticket Created for both bug reports and feature development on the bug tracker., read all the discussions and check if the patches are ready to land in your minor version or not.
- Bug scrub meetings: these take place in the #core Slack 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 and is about sorting Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets to check if the patches and improvements are on track. You have to ask the Component Maintainers, designers, accessibility 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) specialists or focus leads to help their resolution. We must plan a bug 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. scrub a week or two prior to the release.
- Dev chats: the weekly meetings of the Core team to discuss progress of the current release, to talk about future releases and to focus on particular points. I had a hard time on that side for the first dev chat I led with the launch of a lively discussion around Gutenberg 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/’s merge proposal and WordPress versioning. In this kind of situation, you have to stick to a rational approach and try to allow everyone to express themselves.
- Post writing, Trac tickets answering, codex editing and all stuff related to communication. This is very time consuming, so prepare it carefully.
You must also organize yourself for the release process. The complete process is detailed in this handbook: Releasing minor version.
Key moments of a WordPress release
- D-30 to D-15 – here you are, leading the next minor version of WordPress:
- You should go around all tickets tagged for this minor version. Take time to read each ticket carefully. During your bug scrubs, you’ll have to be comfortable with each of them, especially with their progress and last discussions. Feel free to get in touch with the related Component Maintainers.
- Feel free to check out other tickets tagged for the next major 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. and are already committed. It is quite possible to bring them back to your minor if they are self-contained fixes (and not enhancements) and do not result in any new file being created in WordPress core. We were able to repatriate 5 or 6 patches WP 4.9.5. Personally, I managed a spreadsheet with all the tickets to watch. This document helped me a lot later.
- Prepare each bug scrub and dev chat in advance: it’s better to copy and paste at these meetings so you can follow the discussions as well.
- Ask for access to write posts on Make/Core and to be able to notify contributors in the core Slack channel with @here command.
- D-15 – Beta 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. release:
- Last bug scrub: all tickets must be committed in the branch 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".. Those who are not ready must be “punted” to the next release. Do not take any risks.
- One day before, contact lead developers to make sure someone will be available to build your RC One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). package. Do not make the same mistake we made: we ended up with a ready beta but no one to build the package. You must warn Mission Control people in advance!
- Publish your post on Make/Core : reuse previous posts format and indicate changes so people can test your beta.
- D-7 – Release candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).:
- Final Bugscrub: Some last tickets may be committed for RC, but they must have been checked by an experienced core-committer and approved. Besides, two checks are better than one.
- One day before, contact Mission Control to make sure someone will be available to build your RC package.
- Publish your post on Make/Core.
- Bump version number and update changelog for all concerned bundled themes. Here is the standard Trac ticket I made.
- Get in touch with the Akismet team to check if a new version is ready to land in the release.
- Get in touch with the people in charge of bundle themes and ask them to prepare to deliver a new release of the related themes on w.org.
- Get in touch with Mission Control team and ask them for their availability for the D-day.
- Get in touch with the Security team (usually they will come to you) to know if security patches will land in your release (we had three security patches). Obviously, this information is confidential, you can not communicate it.
- Prepare the changelog of the new version with the complete list of changes for the Codex changelog (if the release contains security patches applied to all the supported branches, it would be necessary to make a new page for each version!) And for the Make/Core post.
- Build the packages (current branch + previous branches if a security patch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. is delivered) with Mission Control team.
- Ask Meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team to prepare the list of contributors of the release and to update credits API 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..
- Prepare to publish the Make/Core Post and the /News Post, they must be published right after auto updates start.
- Prepare some standard announcement such as “@committers please refrain from committing while we package the 4.9.5 release.” or “Heads up to everyone following along: We’re in the process of releasing right now. You’ll see some builds appear in this channel, but we have not released until there is a new post on WordPress.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//news/. Please do not tweet, publish, or otherwise announce a release until there is a public post about it on WordPress.org” for Slack, to repeat regularly during the build process.
- Prepare local test instances to test each package of each version of WordPress on different PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher environments. Hopefully, other contributors can help you test the packages on their side.
Once launched, that’s the big day. The release is built and auto updates will be done on WordPress installations around the world. Feel free to ask the Mission Control for some statistics – the figures are incredible. Unfortunately, it is not publicly available, but you will certainly be pleased to know in real time the number of people who are enjoying your work.
At the next devchat, you will carefully follow the feedback from the Support Forums team who will give you feedback from users. Fortunately, in our case, nothing went wrong.
- Remember to warn the people who have Mission Control access a day or two before each release (beta, RC, final release). Without them, you can’t do anything! In our case, we did not manage the beta and the RC very well and only succeeded at the last moment. Thank you for those that helped, who were understanding and caring.
- An issue when you are relatively new in Core development is to find the right people to contact. Do not hesitate to get in touch with as many people as possible, they will put you touch with the people who can help you. Remember: you can’t build a WordPress release alone.
- Do not hesitate to get in touch directly with the people who can help you: Component Maintainers, Focus Leads, Theme and / or Plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party Teams, Mission Control, Security. A little introductory message at the very beginning of the release does not hurt, and everyone will be very happy to help you if needed.
- Attend as many component/focus meetings as possible. Some changes may affect your release and it allows you to know how specific tickets are doing.
- Plan about three evenings a week to work on the release, during a month. It depends on your timezone but in my case, I had to book at least every Tuesday and Wednesday evening, sometimes until very late at night. Outside, you will also follow what happens in the tickets throughout the week. Tell your boss to get some time for it (thanks to my agency for giving me some time during office hours).
- Organize well so you do not have any last minute surprises. For example, we were ready to integrate the “Try Gutenberg Callout” or not, and we considered both solutions, whether on the general organization or during changelogs writing and blog (versus network, site) posts on Make/Core.
- If you are running as a co-lead (which is better), alternate the lead equally so that everyone can enjoy the experience of triage, bugscrubs, developers chats and the whole release process.
- [more personally] If you are not a native English speaker, it’s not the end of the world: focus on putting your ideas first. Nobody will reproach you for not speaking perfect English. WordPress contributors are kind, understanding and professional people.
- Enjoy all this because time flies!
In conclusion, leading an open source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. project is above all, rewarding and difficult. It’s no easy feat to manage a team of volunteer contributors and ensuring things run smoothly is a challenge in and of itself, let alone the bugs! Constant communication and asking questions will always put you ahead. No one should feel ashamed to ask an easy question and those kinds of questions are very welcome. Sharing knowledge is more powerful than feeling bad that you don’t know the answer. You should also feel like you can lead too. This doesn’t mean telling people what to do, but being firm and leading and making decisions makes everything move forward much more quickly. To sum up, the human part is just as critical as the technical part of the project.