I agree that we should be able to fix mistakes, my only suggestion was that those mistakes not be non-trivial. But the more I think about it, the more I feel convinced about just publishing the updates - however, having a time stamp on when the guide was last updated would be nice to have. Anything else would require much more effort and I'm not sure it's worth it.
On Wed, Sep 18, 2019 at 2:48 PM Chris Hostetter <[email protected]> wrote: > > : > However Anshum does make a good point that users wouldn't know when > : the pages have changed. I think it would be great to have a link on each > : ref-guide page that shows the last modified date and links to the > : history of that page in github > > : Perhaps we could instead provide a single HTML page or HTML table as > : part of or alongside each guide, showing all commits touching the guide > : on that branch after the release. Could probably be baked in as part of > : the release script. Using the release date or git hash for the release, > > Yeah, there are a lot of options we could pursue for generating a > "changes" list as part of an automated build process -- but i would > consider this idea a "nice to have" feature that shouldn't block moving > forward. > > Given 2 options, I would much rather: > a) have the ability to quickly/easily "fix" mistakes/ommisions in > "official X.y ref-guide" on our site and have it automatically republish, > w/o it being immediately obvious to users that a page may have changed > between yesterday and today. > ... over ... > b) *NOT* being able to re-publish at all just for the sake of users > knowing that the (incorrect) content they are reading is consistent > between yesterday and today. > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Anshum Gupta
