Everything here sounds great (+1 from me) but... On Thu, Aug 18, 2016 at 7:30 PM Chris Hostetter <[email protected]> wrote:
> But the other nice thing is that this will make it easy to > maintain "branches" of the ref guide in git, and publish those with > releases as well -- so you can edit the docs on master, and backport the > docs to the branch_6x at the same you backport the feature, and we can > publish HTML versions of the guide right along side the javadoc docs for > each version of solr. > Ugh! I think it's a PITA that we basically always back-port all commits to another branch, and the prospect of having to do this to documentation as well will add a large barrier to editing the docs. I propose an alternative way: Like having everything go into a 6x branch and then have the 7x branch be only for things unique to 7x? From time to time and definitely when 7.0 arrives, we then merge 6x into 7x. Some things we will need to remember to remove from 7x, and there will be merge conflicts, but I think the down-sides there far outweigh the lower barrier to editing the documentation. Make no mistake, for all the numerous benefits of moving to a source-control based editing, it will become harder to make small edits/fixes to the docs. In under 15 seconds I can fix any trivial typo in Confluence. We need to recognize this with eyes wide open before choosing the trade-offs. I still think it will be a worthwhile trade-off *if* we strive to make editing the docs in the new system as easy as possible. Needing to usually commit to two branches is a *huge* blow to that. As it is, apparently I need to go finding some asciidoc IDE that I didn't need yet. Not for typo fixes of course, but any way my browser isn't enough any more. ~ David -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
