Automatically publish canary releases

[herregroen]

Explanation

Currently there's a lot of complexity around linking the monorepo in Travis to ensure Travis is using the intended versions of our packages when testing.

The root cause of this is that as the packages haven't yet been published to NPM it's impossible to accurately specify which version should be used.

For this the following issue was created: https://github.com/Yoast/wordpress-seo/issues/13139, however many of the conditions specified there are impossible to resolve with the information available in Travis.

To fix this in a more comprehensive manner I believe we should use lerna's publish canary feature: https://github.com/lerna/lerna/tree/master/commands/publish#--canary.

I would suggest that on every commit on the develop branch the following happens:

• a canary release with the develop dist-tag is published for every package changed.
• The trunk branch of wordpress-seo is automatically updated to the latest develop versions of all @yoast packages.

I would suggest that on every commit on the hotfix/* branch the following happens in addition to the current releases:

• a canary release with the hotfix dist-tag is published for every package changed.
• If a wordpress-seo branch with the same name exists then that branch is updated to the latest hotfix versions of all @yoast packages.

Lastly I'd strongly consider replacing the current rc releases with the same mechanism, on every commit on a release/* branch the following happens instead:

• a canary release with the prerelease dist-tag is published for every package changed.
• If a wordpress-seo branch with the same name exists then that branch is updated to the latest prerelease versions of all @yoast packages.

This should significantly ease development flows and ensure the only case where we have to link the monorepo in travis is in the case of two branches with the same name. In all other cases the package.json release can be used as we'll now finally an accurate tag for every single commit that's automatically updated in wordpress-seo. As soon as a PR gets merged here then the accompanying PR on wordpress-seo can simply pull the latest trunk and it will have the required features.

[IreneStr]

Sounds good!

One note: we need to find a way to include adding changelog items when publishing a (pre)release or hotfix.

Question: in the last part you write about making prereleases on every commit on the release branch. Will we also do a 'real' release just before the wordpress-seo release?

[herregroen]

Sounds good!

One note: we need to find a way to include adding changelog items when publishing a (pre)release or hotfix.

Question: in the last part you write about making prereleases on every commit on the release branch. Will we also do a 'real' release just before the wordpress-seo release?

Regarding changelogs. Considering none of these are actual releases that someone will install unless explicitly asking for them I'd consider changelogs a nice-to-have rather than a must-have. Not to say they're not important, but we can start doing canary releases without changelogs and improve the automatic process later.

Regarding 'real' releases. This gives us the freedom to do plugin releases without necessarily doing a complementing javascript release. So I think we should consider detaching NPM releases from plugin releases. If we have code that's a sufficient improvement and sufficiently stable then we should do a full NPM release, which we can do at any time. I think we'll be most productive when Yoast SEO is generally on the bleeding edge of our own JS libraries and thus rarely, if ever, on a full release and always using one of the prereleases.

That also opens up automating the plugin release even more.