That sounds like a pretty good plan to me. What do others think?
On Sun, Jan 9, 2022 at 4:04 PM 张铎(Duo Zhang) wrote:
> That's also a possible solution, I mean remove purge the docs in branches
> other than master.
>
> So what should be done will be:
> 1. Remove all docs from branches other than
That's also a possible solution, I mean remove purge the docs in branches
other than master.
So what should be done will be:
1. Remove all docs from branches other than master.
2. See how to skip the doc generating when docs are not there so we do not
break the publishing release process.
3.
Our branch-1 release process included a step to check out master and overwrite
root src/ to do just that, manually synchronize docs for all releases.
I do not believe we can keep docs in branches effectively synchronized.
Periodic manual sweeps could work but is still error prone. It would be
As you say the docs on branches are not updated in any principled way.
Extracting the Javadoc from a matrix of branch builds in a automated way for
publishing up to the website would be feasible. We can add this to the build
website Jenkins job.
On the other hand, this thread’s topic, a
Ouch. IIRC there are lots of documentation improvements only get
merged to master branch only...
I think the fact for now is that, it is a bit hard for us to keep the
documentation for each minor release in sync correctly...
Since we will publish the ref guide as part of our releases, let's
just
We already publish version specific reference guides as a part of our
binary tarballs. My understanding is that's a big part of why they're
still in the main source repository; that we get docs built as a part
of our assembly.
e.g. just picking a 2.4 release I have handy:
(base)
