Package names for the official wp-cliGitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ organization need to be discussed upfront with the maintainers.
Before creating a new repository, it’s important to discuss the repository first. This discussion helps establish consensus on what purpose the codebase serves, and where it lives best in the WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/ ecosystem.
Package names for WP-CLI commands must end with the -command suffix for clarity, and also to distinguish them from the non-command repositories.
Before new repositories are created for commands, a decision needs to be made whether the command deserves its own repository or whether it should be included within an existing repository instead.
Patch releases (e.g. 1.0.x) are used for bug fixes, documentation changes, small enhancements, etc.
Minor releases (e.g. 1.x.0) are used when a new command is introduced to a package, or a major enhancement is made to an existing command.
Major releases (e.g. x.0.0) are used when changes to the framework change the WP-CLI APIAPIAn 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. in a breaking way.
Open milestones usually point to the next version to be released.
As the release notes are built using the milestones, both pull requests and issues that are to be merged need to be set to the upcoming milestone, so that these pull requests will be part of the release notes.
Labels can be part of a label group, a concept that is applicable to all packages. The actual labels that are available can depend on the actual package, but the groups always have the same semantic role.
The labels that define what scope the current issue/pull request applies to are prefixed with scope:.
scope:bootstrap – Part of the bootstrap process, which loads both WP-CLI as well as WordPress CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress..
scope:distribution – Part of the distribution process, where the Phar is being built and releases are produced.
scope:documentation – Part of the handbook, command reference or inline help.
scope:framework – Part of the WP-CLI framework itself, which provides the architecture, API and helper functions to make commands possible.
scope:testing – Part of the unit or functional tests.
scope:website – Part of the website infrastructure on wp-cli.org or make.wordpress.org.
The upstream-bug label denotes an issue that is a bug in upstream software (e.g. WordPress core, PHPPHPPHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php., etc.) that won’t be fixed in WP-CLI.
Non-trivial pull requests should be preceded by a related issue that defines the problem to solve and allows for discussion of the most appropriate solution before actually writing code.
If a pull request is submitted by one of the committers, the submitter should set the “Reviewers” for that pull request to wp-cli/committers if a general code review is needed, or to one or more specific committer profiles if the expertise of a specific person is needed/wanted.
If a pull request is submitted by an external contributor, the committers should be responsive and provide quick feedback to encourage further contributions.
Sometimes, a pull request may not be mergeable, no matter how much additional effort is applied to it (e.g. out of scope, etc.). In these cases, it’s best to let the contributor down as softly and firmly as possible, both to encourage future involvement and avoid flame wars.
Make sure to:
Thank the contributor for their time and effort.
Fully explain the reasoning behind the decision to close the pull request.
Link to as much supporting documentation as possible.
If you’d like a template to follow:
Thanks ________ for the time you’ve spent on this pull request.
I’m closing this pull request because ________. To clarify further, ________.
For more details, please see ________ and ________.
Apart from needing to be approved, pull requests also need to have their tests in a passing state before they can be merged. When both of these conditions are true, any committer can merge the pull request by:
Ensuring that all applicable labels have been set.
Ensuring that the correct milestone has been set.
Ensuring that the branch is deleted after the merge (if applicable).
Adapting the title of the pull-request as needed. The ideal pull request title is one that can be copied and pasted into release notes as is.
Once a pull request is merged, the committer should make sure any corresponding issues are also closed and assigned to the correct milestone.
Package releases happen on an as-needed basis and are executed by the maintainers. A package is tagged for a release when:
It has a reasonable number of changes that have been sitting for a while (couple weeks or more) and would benefit from landing in the nightly build.
It has a substantial enhancement (e.g. a new command) that’s worth getting into the nightly build for pre-release validation.
Tagging a release should be postponed (for a few to several days) if there’s an open pull request that makes sense to include in the release.
Package release notes should include the subject of and a link to each merged pull request. It’s not necessary to include minor documentation, coding standard, and test suite changes. Feel free to edit the subject for clarity. See wp-cli/scaffold-command v1.0.6 for an example.
Importantly, tagging a package release is also an opportunity to perform a final review of product quality:
Each merged pull request makes sense to ship, and has sufficient test coverage and documentation.
The package’s README.md is up-to-date.
No breaking changes were introduced, unless explicitly intended.
Sometime after a new package version is tagged, the wp-make-coffee bot submits a pull request against wp-cli/wp-cli with the results of composer update. When this pull request is merged, the package release will end up in the WP-CLI nightly build.