On Thu, Sep 7, 2023 at 11:40 PM Jeff Mesnil <jmesnil(a)redhat.com> wrote:
On 7 Sep 2023, at 22:45, James Perkins <jperkins(a)redhat.com> wrote:
>
> The source of these guides would be in
>
https://github.com/wildfly/wildfly/tree/main/docs/src/main/asciidoc.
> Having the doc being closer to the source will incentivize developers to
> add and maintain them :)
>
I actually think keeping these elsewhere makes more sense. They should
likely just live in
https://github.com/wildfly/wildfly.org or a separate
repository all together. If we need to update a guide because it has an
error, how would we do that? If we just make a PR to the main WildFly repo,
we'd need a release to see the change.
Technically, we don’t need to release WildFly to push its content to
wildfly.org, we would just copy its content.
But this might be inappropriate if it picks up a guide for something that
has not been released yet.
I like your other approach and we can make it a seamless integration:
* have a dedicated
github.com/wildfly/guides that contains the guides (in
Asciidoc) as well as the same web site L&F than
wildfly.org
* use GitHub page to publish it to
https://docs.wildfly.org/guides
With that setup, we could aded/update guides independently of WildFly
releases.
I think this makes sense and I like this approach.
Along these lines, because I'm thinking about this for another project, is
for new feature guides maybe we have a dev branch or something that once
released we merge into the main branch. That way we can create guides for
new releases without affecting the current guides. The other option is just
labels and merging when released.
Jeff
—
Jeff Mesnil
Engineer @ Red Hat JBoss EAP
http://jmesnil.net/
--
James R. Perkins
JBoss by Red Hat