> > But I do not want to confuse users with documentation that does not match > a released plugin. Pulling the docs from master would be a no-go for me. > The master branch may contain work in progress and I do not want to cut a > release just to keep the docs consistent or up-to-date. Pulling the docs > from a separate branch, similar to gh-pages would be nice. Plugin > maintainers could update the branch any time, either on release or in > between for fixes. >
Are there any plugin developers who feel the same as @Daniel ? On Tue, May 17, 2016 at 8:43 PM, Daniel Spilker <m...@daniel-spilker.com> wrote: > On Tue, May 17, 2016 at 3:26 PM, Robert Sandell <rsand...@cloudbees.com> > wrote: > >> I don't think we should have to rely on having to make a release just to >> get a fix into the documentation. >> The doc generation should be just picked from the master branch during >> the static generation of jenkins.io unless that would take too much time. >> That way a pull request with a new feature in it could also contain a >> documentation update in the same PR, I believe the Jenkins DLS plugin is >> doing it that way. >> > > Job DSL keeps the documentation in the source repo ( > https://github.com/jenkinsci/job-dsl-plugin/tree/master/docs), but the > "official" documentation is copied to the GitHub wiki on every release. > There is a nice Gradle plugin for doing that ( > https://github.com/jenkinsci/job-dsl-plugin/blob/job-dsl-1.46/build.gradle#L196-208). > I'm really looking forward to moving the docs to jenkins.io. > > But I do not want to confuse users with documentation that does not match > a released plugin. Pulling the docs from master would be a no-go for me. > The master branch may contain work in progress and I do not want to cut a > release just to keep the docs consistent or up-to-date. Pulling the docs > from a separate branch, similar to gh-pages would be nice. Plugin > maintainers could update the branch any time, either on release or in > between for fixes. > > I would also like to propose that the README file in the repo is NOT the >> main user documentation index file, it seems to be tradition that that file >> is aimed at people currently browsing the repo and hence aimed at >> developers more than users. It doesn't hurt to include it in the plugin >> docs but it shouldn't be the front page. >> > > +1 for a clear separation of users and contributors, those are two > different roles with different needs. > > Daniel > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/kNZMOsF_ueA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAKqW32ACUHx-0bLXG0Ar_eQqupTO6h-LPTdCC1GNJEgXSvDkmQ%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAKqW32ACUHx-0bLXG0Ar_eQqupTO6h-LPTdCC1GNJEgXSvDkmQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- KInd Regards, Cynthia Anyango -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFcxnmoExS%2Bf%2BM0fekb6iffWeA6NWn92XRdDKKHPHfkvEwwL4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
