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, >
