Pavel,
As far as I can see, all your pros points work just as well for a
separate repository (except for "everybody knows about it"). I don't
mind keeping the docs in Ignite repo as long as I am able to freely
commit to master. Will I be able to do that?
-Artem
On 23.06.2020 14:04, Pavel Tupitsyn wrote:
Ilya, Artem,
"Separate repo just because we can't finish docs before release"
does not make sense to me. My proposal is:
- Working version is in the master branch
- When a release branch is created, e.g. ignite-2.9, we create
ignite-2.9-docs and update it as long as we want.
Pros (compared to a separate repo):
- Docs can be updated along with the code, same review process
- Visibility - everyone knows about main repo, docs are searchable together
with code in the IDE
- Code snippets can reference the actual code and we make sure they compile
- Code snippets can be tested on TC
GridGain uses a separate repo for their docs, and it proved to be less than
optimal.
Especially when adding samples for new APIs which are not yet released.
On Tue, Jun 23, 2020 at 1:19 PM Artem Budnikov <a.budnikov.ign...@gmail.com>
wrote:
Pavel,
Yes, I mean a separate repository. The reason is that documentation is
usually updated after the product version is released. As Ilya pointed
out, keeping the docs in the main Ignite repository would entail
completing the docs before the release date, which is not possible under
current circumstances.
Ilya,
You can look at your company's documentation for a working prototype
turned production-ready approach. The approach has been tested for a
while and proved to be successful, at least with respect to our goals here.
-Artem
On 23.06.2020 12:48, Ilya Kasnacheev wrote:
Hello!
I'm not really sold on the github version yet, I would like to see a
prototype of such documentation before deciding, so for me it'w
0
Pavel, we don't have enough discipline to make sure that all
documentation
is ready at the time of release, and we may need to add notices here and
there after a release is already out. This means, separate git
repository,
or at least separate git tag on that repository, is needed.
Regards,
