Pin branch used to build handbook

[oandregal]

NOT TO MERGE YET.

Fixes #14303

This will pin the branch contents that will be used to publish the Gutenberg handbook.

Note that current handbook includes contents that people depend on (published posts that point to the handbook, etc.) so we can't pin the handbook to wp/5.1 because that will unpublish the contents.

I'm proposing this to be merged during/after WordPress 5.2 release.

[youknowriad]

What I don't like about this, is that if forces us to have a commit each time we update the base branch. I'd rather use relative links and avoid introducing these commits.

[oandregal]

What I don't like about this, is that if forces us to have a commit each time we update the base branch. I'd rather use relative links and avoid introducing these commits.

@youknowriad mmm, unless I'm missing something, my understanding is that we'll have to keep the branch name somewhere: if not here, it'll be in the importer plugin (as proposed in the core patch). So, we end up always having to change the branch name somewhere on any WordPress release. We may have a preference of place over the other, and that's OK. It just occurred to me that doing it in the Gutenberg GitHub repo will make us more agile (we tend to know git better than svn and there are more eyes here to approve such a change).

Perhaps a different approach that doesn't require changing branch names will be to build the docs into a specific branch. Anyway, we'll need to update that branch during a WordPress release.

[mkaz]

Creating docs in specific branches for each release is an interesting way of doing it, because than it is clear which version of docs goes with which release and could be made to be browsable.

This is the way Laravel does it here: https://github.com/laravel/docs
And then their documentation is browsable by version here: https://laravel.com/docs/5.8/

[youknowriad]

@nosolosw Regardless of what we do in the Gutenberg project, Core has to keep the branch name it's currently showing in the handbook somewhere and updates it each time we do a new major version of WordPress.

Relative paths allows us to only care about this in the caller side (importer plugin) while in the repository, no matter what branch we're in the docs are always in sync and don't require us to update the base branch in the manifest each time we create a new branch.

[oandregal]

Closing in favor of #14739