-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lts-doc: sort documentation alphabetically #3652
Conversation
Awesome! |
Fixed. |
Reorders, without contextual change, the assert documentation alphabetically.
03818c4
to
128069c
Compare
/cc @nodejs/documentation |
Reorders, with minimal content duplication, the buffer documentation alphabetically.
Reorders, with no contextual changes, the child_process documentation alphabetically.
Reorder, with no contextual changes, the cluster documentation alphabetically.
34c9d69
to
4d9a7e6
Compare
Reorders, with no contextual changes, the console documentation alphabetically.
Note that this cannot land directly against v4.x, it would need to land against v4.x-staging. Also, my concern with this is that if the equivalent changes are not made in master, it will become much more difficult to simply cherry pick commits for doc changes from master to v4.x-staging in the future. Ideally, these changes would land in master first, then get cherry-picked and modified back in a PR to v4.x-staging. /cc @nodejs/lts |
With that comment, @jasnell, Are you saying I should checkout a new branch off of master and make the changes there? I figured that with master being at v5/v6, the changes in the docs would be too much for backporting. |
I don't want to discourage the work, it's good stuff. However, the process we've been following the landing in Stable and LTS branches is to first land things in master then cherrypick back to the relevant branches. For LTS, the commits land first into For instance, if we go through a reorder everything in v4.x but don't make the corresponding change in master, then someone goes and makes edits in the same doc in master, when it's time to pull those back we end up having to reconcile a number of conflicts as opposed to a simple Right now, the deltas between v5/v6 are small enough that pulling stuff back to v4 is simple. It will get more difficult as the gap widens but even then, we want to minimize the differences between v4 and master as much as possible. As we go along, there will be changes that need to be made that only apply to v4. Those would still need to land as commits to v4.x-staging. I don't want to discourage this work, however. It should just be done in a way that ensures parallel changes are being made in master and v5. |
Reorders, with no contextual changes, the dns documentation alphabetically.
Okay, @jasnell, so the action to be taken is to open a PR against master? If so, I'll start the diff/merge on my end, close this (actually I can't), and open a new PR against master. |
Yes. And I would recommend one commit per file modified the way you've been
|
closing. re: #3662 |
As a follow up to #3651, and to #393, I've started from the top and am working my way down.
This is a WIP! Against v4.x!
I am posting this now because it is a big diff and will need eyes.
Docs that have been completed:
Help is more than welcome!