Github - make PR's for the user manual against 'hotfix' branch instead of 'develop'

following up on a discussion on my PR for changes in the user manual Patch 1 by vrms · Pull Request #6372 · frappe/erpnext · GitHub

I understand that ‘develop’ will be merged less frequent (maybe just at release upgrade [7.0 > 7.1 i.e.] ) then the ‘hotfix’ branch. That’s totally understandable and should not be questioned here.

But as user manual entries can’t hurt the system it should be non-problematic the merge them into master more quickly (which everybody benefits from) through the ‘hotfix’ channel. Therefore I want to propose that PR’s to the user manual are being made against ‘hotfix’ by default.

1 Like

The documentation is always updated with the develop branch :slight_smile:

In more detail : The team takes the develop branch, generates documentation for it into a folder, and that is pushed into the gh-pages branch on the Github repo, which is then read by GitHub pages.

If your changes aren’t updated yet in the documentation, it’s because it’s not yet been generated and pushed.

You can, in fact, generate docs using the latest develop, and then make a PR to the gh-pages branch. Here’s some docs for that (Refer to “Setting up output docs” and onwards) :

1 Like

What I am doing is whenever I consult the manual and see something I don’t understand I click on the ‘enhance this document’ button which creates in the end a patch-x branch on my fork of ERPNext, which then creates a PR against ‘develop’ by default.

Is your suggestion to do such a PR against ‘gh-pages’ instead (which will appear online faster then ‘develop’?

No no, make PRs to develop itself. Once it’s merged, you update your local erpnext repo. After that you follow the “Setting up output docs” of the above page I linked. Then just run bench --site [site] build-docs [appname]. This will generate the documentation in the new docs folder you created. Commit these changes and push them to your fork of the repo, then make a PR with that. I hope that makes sense.

if that is a suggestion for (not yet existing) v7.1 where (assumption) the user manual will be living & available in my instance (instead of centralized … then, yes