Hi there Dave,
I can understand the frustration that you face. I think the freezing of the
code is different to that of the docs. I think each project member would agree
if I stated that changes to the docs on ANY branch should be allowed regardless
of where in the process of the release the
John,
Thanks for acknowledging that docs are just as important as code! As a
career tech-writer, the "docs=code" model appeals to me.
I get what you're saying, and have worked in environments where release
managers have enforced such constraints.
In this vein, the Geode code is well-supplied with
Personally, I believe doc is a critical component to any software project,
especially a project like Apache Geode, and so, is the project really “complete
“(or should thee codebase really be frozen during a release) if the doc is not
done or consistent yet?
Having the doc be part of the
I don’t see any downsides to this approach. We already do this for other assets
like examples, native, site, and benchmarks.
> On Jun 14, 2022, at 12:03 PM, Dave Barnes wrote:
>
> ⚠ External Email
>
> I'd like to move the doc sources for the Geode User Guide from the code
> repo
>
I'd like to move the doc sources for the Geode User Guide from the code
repo (https://github.com/apache/geode) to a separate geode-docs repo.
The primary reason is to allow docs to cycle at their own rate, rather than
in lock-step with the code. The present arrangement causes problems during
I have raised this issue a few times. All over our API we are inconsistent with
time. Either in the use of sentinel values or time units. Given the current API
and breaking that is not an option until some major release the best thing you
can do is not use the sentinel values. If you want
Thanks for your answer, Darrel.
If the breaking change is not a viable option, how about at least having both
clients agree on the -1 value (currently -1 is not supported by the native
client) to mean never idle expire and never load condition respectively?
It is true that they will not agree
