Packages: Finalize the revised strategy for npm publishing #39389
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gziolo
force-pushed
the
update/npm-publish-workflow
branch
from
d4d73eb to
cd04857
Compare
gziolo
changed the title
gziolo
commented
Mar 16, 2022
gziolo
added
[Type] Project Management
gziolo
requested review from
ntwb,
nerrad,
ajitbohra,
mkaz,
ryanwelcher and
juanmaguitar
as code owners
|
Size Change: 0 B Total Size: 1.16 MB ℹ️ View Unchanged
|
gziolo
commented
Mar 16, 2022
| run: | | ||
| cd main | ||
| npm ci | ||
| ./bin/plugin/cli.js npm-latest --semver minor --ci --repository-path ../publish |
There was a problem hiding this comment.
Please note, that it's going to be a regular npm publishing from now on. Not the test one like last week 😄
gziolo
force-pushed
the
update/npm-publish-workflow
branch
from
f4a0c51 to
1709981
Compare
tellthemachines
approved these changes
Mar 17, 2022
docs/contributors/code/release.md
Outdated
| - [Synchronizing Gutenberg Plugin](#synchronizing-gutenberg-plugin) (`latest` dist tag) – publishing happens every two weeks based on the newly created RC1 version of the Gutenberg plugin. | ||
| - [WordPress Releases](#wordpress-releases) (`patch` dist tag) – only when bug or security fixes need to be backported into WordPress Core. | ||
| - [Synchronizing Gutenberg Plugin](#synchronizing-gutenberg-plugin) (`latest` dist tag) – publishing happens automatically every two weeks based on the newly created `release/*` (example `release/12.8`) branch with the RC1 version of the Gutenberg plugin. | ||
| - [WordPress Releases](#wordpress-releases) (`patch` dist tag) – publishing gets triggered manually from the `wp/*` (example `wp/6.0`) branch. Once we reach the point in the WordPress major release cycle where we only cherry-pick commits from the Gutenberg repository to the WordPress core, we use `wp/*` branch for npm publishing with the `patch` dist-tag. It's also possible to use older branches to backport bug or security fixes to the corresponding older versions of WordPress Core. |
There was a problem hiding this comment.
Might be worth mentioning that this point is usually after the first Beta?
There was a problem hiding this comment.
Yes, the first beta seems like a special case where we take the content of the latest wp/latest into wp/xx and do the release. How do we do that? Should we document it.
There was a problem hiding this comment.
We will have to figure out this part together with @adamziel around WordPress 6.0 beta 1. Maybe it's something that should be scripted and triggered from GitHub UI? Example:
- Create
wp/6.0branch fromwp/latestor mayberelease/13.0(or whatever the last release is). - Request a major version bump in all production packages by inserting an entry in CHANGELOG files with a note that it's the beginning of the future major WP release. That part is confusing even for me to explain. We would have to write something strange that translates to this – this release won't be included in WordPress 6.0 because this is based on the Gutenberg plugin that is planned for WordPress 6.1 😅
Can we somehow trigger that automatically from GitHub actions based on any event? This feature freeze in Gutenberg is a bit fluid and differs between major WP releases.
There was a problem hiding this comment.
Can we somehow trigger that automatically from GitHub actions based on any event?
I think since the dates for betas are "manual", we need to have a job that we can trigger manually. We can leave this part for later for now, but it's important to document at least 👍
There was a problem hiding this comment.
I will include some initial notes for now and iterate later based on learning from WordPress 6.0 release process.
There was a problem hiding this comment.
It should be fine to follow more or less the same process that we have until now for creating the release branch, except we do it earlier in the cycle. To be safe, we should create wp/6.0 straight after we do the last package updates for Beta 1, because that's the point at which the Core feature freeze starts.
Request a major version bump in all production packages
I know we're not exactly following semver 😅 but even so, isn't it better to keep the major versions for actual breaking changes? Or are there advantages to having them follow the WP release schedule? Considering the block editor can be used independently from WP, it would be good for the versioning logic to also be somewhat independent from it.
There was a problem hiding this comment.
I guess minor would be enough in most of the cases, but I doubt we do a good job including CHANGELOG entries for every new feature or API. We use a lot of experiments as well, so for more high-level packages we probably should do a major version bump every two weeks to have a more honest semver increments. In general, it's hard to have a good semver strategy with so many low-level packages. One thing is clear. We need at least do a minor version bump for every major WP release so we have a way to publish big fixes that target older WP releases.
youknowriad
reviewed
Mar 17, 2022
| - The `wp/next` branch contains the same version of packages published to npm with the `next` distribution tag. Projects should use those packages for development purposes only. | ||
| - A Gutenberg branch targeting a specific WordPress major release (including its further minor increments) is created (example `wp/5.2`) based on the `wp/trunk` Gutenberg branch when the corresponding WordPress release branch is created. (This usually happens when the `beta` or `RC` of the next WordPress major version is released). | ||
| - The `wp/latest` branch contains the same version of packages as those published to npm with the `latest` distribution tag. The goal here is to have this branch synchronized with the last Gutenberg plugin release, and the only exception would be an unplanned [bugfix release](#standalone-bugfix-package-releases). | ||
| - The `wp/next` branch contains the same version of packages as those published to npm with the `next` distribution tag. It always gets synchronized with the `trunk` branch. Projects should use those packages for development or testing purposes only. |
There was a problem hiding this comment.
Seems like this branch and "next" packages become less important if we do wp/latest release on each plugin RC
There was a problem hiding this comment.
Yes, it's true. However, we might make it more useful in the future, too. I used it recently for testing purposes of the publishing workflow. At the moment, publishing with the next dist-tag is a bit noisy in the repository because it creates a git tag for every package published. This is the default behavior in npm and the only way to work around it would be to use canary releases from Lerna and publish changes even daily. I remember having some issues with the broken version bumps with --canary flag so we would have to ignore the excessive number of git tags created or work around it somehow.
gziolo
force-pushed
the
update/npm-publish-workflow
branch
from
0b44f0a to
a0f6fad
Compare
youknowriad
approved these changes
Mar 17, 2022
|
I have just renamed |
jostnes
pushed a commit
to jostnes/gutenberg
that referenced
this pull request
Mar 23, 2022
…#39389) * Packages: Trigger npm publishing earlier in the plugin RC1 process * Update the section for package releases to npm * Update .github/workflows/build-plugin-zip.yml * Clarify details for WordPress releases
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Follow up for #39259.
Related discussion: #37820.
This is another iteration of the automated npm publishing for WordPress packages. The main objectives are:
wp/trunkbranch towp/latestto better express the current role of the branch.4.Why?
There were a few revisions to the npm publishing strategy, but people had too many questions and concerns, so I decided to give it another try and further clarify. One of the confusing aspects was the name of the inherited branch name
wp/trunkthat no longer applies to the new workflow.When reviewing the impact of changes applied in #39259, it became evident that the current configuration is suboptimal. It turned out that I integrated the automated npm publishing workflow after the prerelease post creation for the Gutenberg Plugin RC1. The issue is that the release lead needs to manually publish the editor draft before npm publishing happens, which might cause unexpected delays, which we try to avoid.
How?
I paired on Thursday with @ockham to find a better place to trigger npm publishing earlier in the process of publishing the Gutenberg plugin RC1 release. This should conclude all the automated workflow changes necessary for the revised strategy for npm publishing.
I also collected feedback in the discussion thread #37820 (comment) to propose all necessary documentation changes to make the revised strategy for npm publishing easier to understand.
I have already created a new
NPM_TOKENsecret token inside the protected "WordPress packages" environment (similar to how wp.org access works):I removed from GitHub and invalidated on npm the old token used last week for npm publishing.
Testing Instructions
I don't think there is an easy way to test the automation. We will have until the next Gutenberg plugin 12.9 RC1 release.
The updated section explaining the strategy for npm publishing can be previewed here.