Post docs move #612
Post docs move #612
Conversation
|
There are a few things here and in the broader docs move project that do not quite make sense to me, but perhaps that's just due to lack of explanation...
|
|
|
re 5... we really need that process documented, step-by-step on the wiki. including instructions for how to make a change to the published docs and have the same change go into master. It's probably all just some git command sequences, but they are outside the ordinary day-to-day workflow and hence easy to get wrong. |
|
re 2... it's not a half-way change. The bit I am complaining about does not appear at https://github.com/weaveworks/weave#find-out-more; it's something that got introduced elsewhere. You could just remove it. |
|
Incidentally, 5 is already an issue now. A bunch of changes have been made on the 'master' docs which equally apply to the released version and hence really, really should be published on http://docs.weave.works/weave/latest_release/index.html too. So we also need a documented way of backporting docs from master to latest_release. |
This uses a special branch `latest_release_doc_updates`, as don't require docs to be updated in retrospect for releases other then the latest.
58e47ab to
c9bff8b
Compare
No, if you document how to cherry pick from master to latest_release, I'll do the rest. |
|
The wiki should have sufficient information now, and we can always refine that later anyway. |
|
This LGTM. I have fixed a few typos in the docs. All of my points except 2 have been addressed. I've raised #640 for that. I'd like @paulbellamy to take a look at the mechanics. |
| * [Features](http://docs.weave.works/weave/latest_release/features.html) | ||
| * [Troubleshooting](http://docs.weave.works/weave/latest_release/troubleshooting.html) | ||
| * [Building](http://docs.weave.works/weave/latest_release/building.html) | ||
| * [How it works](http://docs.weave.works/weave/latest_release/how-it-works.html) | ||
| * [Automatic Discovery with WeaveDNS](https://github.com/weaveworks/weave/tree/master/weavedns#readme) |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
What is the process for updating docs on a previous release? Is that something we need to worry about? Or just make another release (e.g. 0.9.0.1) |
We don't. |
Sort of could, but the idea of
Not unlikely, but the worst that can happen is that docs under |
|
I am completely lost now. I have no idea how latest_release_doc_updates works. Is what gets published under the latest_release URL a merge of the latest_release_doc_updates branch into latest_release? |
A commit with tag A tag push would occur as result of someone running To update docs after the release you can either push directly to |
|
So this whole process relies on ci to be operational at the time a change is pushed? |
|
Yes, as otherwise the process would have much more dependencies. We can probably package up a container that developer can use in case CI is screwed, if that worries you. |
|
@ilya: I'm assuming that the gsutils cp command will also be able to remove files? @rade: |
|
Also, we should back-fill the docs for older releases. |
Not bothered. Except, maybe, for 0.10. |
|
Ok, pending the |
It's there already. |
I am not suggesting that we should be able to publish docs when CI isn't operational. But it would be nice if CI picked up any doc changes that may have been pushed while it was down. |
|
@paulbellamy yeah, should probably switch to |
|
Cool, @errordeveloper pointed out that if nothing links to the files anymore it doesn't matter if they're left around. so this LGTM. |
No description provided.