[
https://issues.apache.org/jira/browse/JAMES-3226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17168309#comment-17168309
]
David Leangen commented on JAMES-3226:
--------------------------------------
Good point to re-evaluate the module naming.
"main" only makes sense if there is a top-level view that provides an aggregate
view, but as you pointed out, if we can have an independent index page, that
should probably be enough, so a "main" (or "top" or whatever) becomes
unnecessary. So yes, I agree to renaming "main".
The Antora module names should exactly match the actual James module names.
That means that the debate is **not** about how to name Antora modules. If
there is a problem with naming, it ought to be brought up in the project itself.
The documentation is intended to describe the project as it is, regardless of
whether it is "right" or "wrong", or is intended to be changed.
But: do we follow the exact structure of the projects? It looks like
james-project is so much larger than, for example, jsieve. It may be warranted
to associate Antora modules to james-project modules.
So the question you're really asking is: do we have a single Antora module for
the entire james-project? Or because of the large scope of james-project, do we
break it down into sub-modules.
I propose we start with james-project, and defer that decision until later.
Does that sound ok?
> Provide a process around documentation publishing and deployment
> ----------------------------------------------------------------
>
> Key: JAMES-3226
> URL: https://issues.apache.org/jira/browse/JAMES-3226
> Project: James Server
> Issue Type: Sub-task
> Reporter: Ioan Eugen Stan
> Assignee: Ioan Eugen Stan
> Priority: Major
> Attachments: Captură de ecran de la 2020-07-31 02-34-10.png
>
>
> We have started working on the documentation and it's great.
> We should also document the processes around documentation:
> - when we publish the docs
> - how to publish the docs
> - where to publish the docs
> - when we retire old docs ?!
> This task should aggregate discussion and decisions.
> The process should be written as asciidoc.
> We decided to use antora as a documentation system so the features are going
> to depend on that technology.
> We should have documentation for every release we make.
> This is important since people don't upgrade immediately after release and
> might use an older release for some time.
> I'm not sure if the documentation for all versions should be online.
> We can build zip archives of each documentation release and include it in the
> binary release or publish them for download next to it.
> This way we can keep only the latest 1-3 versions online.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
